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(57) A videographics/video game fabricating sys- 
tem includes a nnulttprocessor based game processor 
console which includes a main central processing unit 
(CPU) which controls editing operations and operating 
system task execution and a game CPU for executing 
the model video game which is loaded into a pluggable 
RAM cartridge. The model video game provides a start- 
ing point from which a user can readily create an original 
video game including desired aspects of the model soft- 
ware. The system permits a user to modify any of the 
game"s moving objects, background screens, music or 
sound effects. The main CPU and game CPU cooperate 
in the game execution and editorial process such that 
an editing screen generated by the main CPU is super- 
imposed on a game screen generated by the program 
executing CPU. The game processing console includes 
ports for interconnection with a wide variety of peripheral 
devices including a standard television set, keyboard, 
game hand controllers, mouse, modem board, an inter- 
face board for coupling the game processor to a person- 
al computer system, floppy disk drive, an external RAM 
game cartridge and a user"s I D card. The system utilizes 
unique "unit" based data structures in which moving ob- 
jects are processed on a unit basis and where each ob- 
ject is assigned a unit ID which is associated with a wide 
range of object, game characteristics, game processing 
and location data including status information, present 
screen display location, object format, character size, 
pose information, collision threshold information, tempo 
information, attribute data, animation data together with 



address pointers identifying other processing related in- 
formation associated with the identified object. A wide 
range of information is likewise stored in data structures 
associated with background screens referred to as 
"stage" data. 
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Description 

FIELD OF THE INVENTION 

This invention relates generally to a method and ap- 
paratus for generating unique videographic computer 
programs. More particularly, the present invention re- 
lates to a video game fabricating system designed pri- 
marily for users who are unfamiliar with computer pro- 
gram or video game creating methodology. Such users 
may conveniently create a unique video game through 
an icon driven, interactive computing system that per- 
mits a video game to be executed, stopped, edited and 
resumed from the point where the editing began with the 
editorial changes persisting throughout the remainder 
of game play 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application is related to the following applica- 
tions which are being filed concurrently herewith. "VID- 
EOGRAPHICS PROGRAM/VIDEO GAME FABRICAT- 
ING SYSTEM AND METHOD", Serial No. 08/332,811 
filed October 31. 1994: "VIDEOGAME/VIDEOGRAPH- 
ICS PROGRAM FABRICATING SYSTEM AND METH- 
OD WITH UNIT BASED PROGRAM PROCESSING", 
Serial No. 08/332,551 filed October 31, 1994; "VIDEO 
GAME/ VIDEOGRAPHICS PROGRAM EDITING AP- 
PARATUS WITH PROGRAM HALT AND DATA TRANS- 
FER FEATURES", Serial No. 08/332,555 filed October 
31 , 1 994; and "SECURITY SYSTEMS AND METHODS 
FOR A VIDEOGRAPHICS AND AUTHENTICATION 
GAME/PROGRAM FABRICATING DEVICE", Serial No. 
08/332,812 filed October 31 , 1994. Each of these relat- 
ed applications is hereby incorporated by reference 
herein. 

BACKGROUND AND SUMMARY OF THE 
INVENTION 

Commercially available video game systems permit 
a user to select, at various points in a game, a wide 
range of game playing options which control the remain- 
der of game play. For example, a user may control the 
movement of a display character to exit a display screen 
in various alternative ways. Depending upon the user"s 
exit choice, the display character enters a different 
world. Such user selected game playing options are part 
of the original game program, which is not altered in any 
way. 

In the prior art, a rudimentary attempt has been 
made to permit a user to modify in limited respects, the 
intended manner in which a video game program oper- 
ates. In this product, a game changing device is physi- 
cally inserted into a conventional video game cartridge 
which in turn is coupled to a microprocessor based video 
game console. The game changing device includes a 
read-only memory (ROM) storing codes likely to be 



changed during the course of a game. The device mon- 
itors the video game microprocessor"s address and 
data bus and transmits to the microprocessor a replace- 
ment code if there is a match with expected values. The 

5 replacement code modifies game play characteristics 
such as the number of lives of a character, the number 
of missiles which may be fired, etc. The user has no con- 
trol over a game editing process with this product and 
has no ability to radically change game play in the man- 

10 ner that is practically realizable in accordance with the 
present invention. Moreover, game play can only be 
changed to permit operations and graphic displays orig- 
inally contemplated within the realm of possible opera- 
tions by the game programmer 

15 Professional video game designers have hereto- 
fore had access to game program authoring tools to aid 
in designing an original games. In such programming 
authoring systems, considerable program designer ac- 
tivity is often required to modify a game under develop- 

20 ment in even very simple respects. For example, chang- 
es that are made to characters in a game are typically 
first made in an original character array, specified by the 
artist who formulated the character images. Any change 
made to characters must then be saved as a new file 

25 and transferred to, for example, a program debugging 
module which introduces the change into the game pro- 
gram under development. Changing the graphics of a 
game under development even with respect to relatively 
simple modifications typically involves a complex proc- 

30 ess of recompiling, reloading and displaying the modifi- 
cation. While a wide variety of sophisticated changes 
may be made to a game program being authored under 
the control of conventional authoring programs, such 
modifications require a high degree of programming so- 

35 phistication and knowledge of game programming tech- 
niques. 

In accordance with the present invention, unique 
video games may be simply created by users ranging 
from a relatively unsophisticated elementary school stu- 

^0 dents to sophisticated game developers. A unique hard- 
ware and software platform enables users to create orig- 
inal games by selecting icons which access more de- 
tailed editor screens permitting the user to directly 
change a wide variety of game display characteristics 

^5 concerning moving objects and game backgrounds. 

Model software containing a model game from a de- 
sired genre of games is loaded into a video game RAM 
cassette and operating system software is loaded into 
a system RAM via a floppy disk. The present invention 

50 permits the user to initiate model game play, stop the 
game at any desired game screen to initiate a "system 
break" editing session during which a system window 
for enabling control over a wide variety of editing fea- 
tures is superimposed on the game screen. The user 

55 then selects a moving object or background scene for 
modification. If, for example, the user selects a moving 
object, then the moving object selected is identified by 
a unit number which is associated with a wide range of 
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game play related characteristics. Once the moving ob- 
ject is selected, further icons are displayed permitting 
the user to completely change the objecf's character dot 
pattern for one or more of the poses associated with the 
object, animation features related to the object, the re- s 
sponses associated with detected game play conditions 
associated with the object, the collection of statuses as- 
sociated with each object, the pattern of the objecf's 
movement, the sound associated with the pattern of the 
objects movement and a wide variety of additional game 
play related characteristics. The screen background 
may be likewise modified by accessing a stage window 
permitting the entire background map, the music asso- 
ciated with the background and a wide variety of addi- 
tional background related features to be edited. 

The exemplary embodiment of the present inven- 
tion uses a multiprocessor based game processor con- 
sole which includes a main central processing unit 
(CPU) controlling editing operations and operating sys- 
tem task execution and a game CPU for executing the 20 
model video game that is loaded into a pluggable RAM 
cartridge. The model video game provides a starting 
point from which a user can readily create an original 
video game using desired aspects of the model game. 
The model video game can be readily modified to such 25 
an extent it appears to be a completely new game. The 
system permits a user to modify any of the game"s mov- 
ing objects, background screens, music or sound ef- 
fects. 

The main CPU and game CPU cooperate in the 30 
game execution and editorial process such that an ed- 
iting screen generated by the main CPU is superim- 
posed on a game screen generated by the program ex- 
ecuting CPU. The game processing console includes 
ports connected to a wide variety of peripheral devices 35 
including a standard television set, keyboard, game 
hand controllers, mouse, modem board, an interface 
board for coupling the game processor to a personal 
computer system, floppy disk drive, an external RAM 
game cartridge and a user"s ID card. 40 

The system utilizes unique "unit" based data struc- 
tures in which moving objects are processed on a unit 
basis and where each object is assigned a unit ID which 
is associated with a wide range of object, game charac- 
teristics, game processing and location data including -^s 
status information, present screen display location, ob- 
ject format, character size, pose information, collision 
threshold information, tempo information, attribute data, 
animation data together with address pointers identify- 
ing other processing related information associated with so 
the identified object. A wide range of information is like- 
wise stored in data structures associated with back- 
ground screens referred to herein as "stage" data. Pro- 
gramming is structured for ease of user editing using 
condition and process related operation tables and unit ss 
pointers that identify object unit data structures which 
are to be processed. Unit operation tables are utilized 
for processing the units and identify both a predeter- 



mined condition and the processing operation to be per- 
formed upon detection of the predetermined condition 
for each unit. Both condition and process operation may 
be changed by the user by modifying these tables. 

These and other objects, features, aspects and ad- 
vantages of the present invention will become more ap- 
parent from the following detailed description of the il- 
lustrative embodiment of the present invention, when 
taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 A is a block diagram of a videographics 
game fabricating system and FIGURE 1 B is a per- 
spective view of the game processor system con- 
sole unit 2 shown in FIGURE 1 A; 
FIGURES 2A and 2B are a more detailed block dia- 
gram of an illustrative embodiment of the game 
processor system shown in Figure 1A; 
FIGURES 3A and 3B are memory maps of a part of 
the system memory space: 

FIGURE 4 is an exemplary on-line networking sys- 
tem in which the illustrative embodiment of FIG- 
URES 2A and 28 may be used; 
FIGURE 5 is an exemplary title screen for access- 
ing the exemplary program authoring tools of the 
illustrative embodiment; 

FIGURE 6 is an illustrative system break screen: 
FIGURE 7 depicts an exemplary character editing 
screen: 

FIGURE 8 is an exemplary screen accessed when 

a user clicks on the character icon: 

FIGURE 9 shows an illustrative "all" status screen 

display for the unit named "Mario"; 

FIGURE 9A is an illustrative key editing screen; 

FIGURE 10 is an illustrative unit animation editing 

screen: 

FIGURE 11 is an illustrative background screen edi- 
tor; 

FIGURE 12 shows an illustrative "map editor": 
FIGURE 13 illustrates how the background of the 
game display screen may be modified by dragging 
a background screen and pasting it onto an active 
background; 

FIGURE 14 shows an illustrative music editing 
screen; 

FIGURE 15 is an illustrative music editor screen 
which permits music attributes to be changed for 
each sound course; 

FIGURE 15A is an illustrative music editor screen 
which permits music to be changed in real time 
while the music is being played back; 
FIGURE 16 is an illustrative screen display depict- 
ing the operation of the auto programmer; 
FIGURE 17 is an exemplary status editor display 
screen; 

FIGURE 18 is an exemplary "stage" window display 
screen which permits a vast range of background 
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character editing; 

FIGURE 19 is a functional representation of the 
Mario Factory title screen shown in Figure 5; 
FIGURE 20 is a functional diagram identifying the 
editing related tools accessible through the "tool s 
box" selection screen; 

FIGURE 21 is a functional diagram identifying the 
model software related editorial features accessible 
during game break; 

FIGURE 22 is a detailed block diagram of the gate io 
array 226 shown in Figure 2A; 
FIGURE 23 shows the superimpose controller cir- 
cuitry; 

FIGURES 24A and 24C are simplified schematic 
diagrams of illustrative RAM cartridge embodi- 75 
ments and FIGURES 24B and 24D show illustrative 
ground, address, data, reset, and power connectors 
for the cartridge; 

FIGURE 25 is a block diagram of reset related cir- 
cuitry in accordance with an exemplary embodi- 20 
ment of the present invention; 
FIGURE 26 is a block diagram of the system break 
hardware in accordance with an exemplary embod- 
iment of the present invention; 

FIGURE 27 is a flowchart which shows the 25 
sequence of operations in accordance with an 
exemplary embodiment of the present invention 
from power on through the appearance of the 
"Mario Factory" utility title screen; 

FIGURE 28 is an exemplary unit work related dis- 50 
play screen: 

FIGURE 29 is a block diagram which functionally 
demonstrates how programming is structured on a 
"unit" basis; 

FIGURES 30A through 300 are a flowchart deline- 3S 
ating the sequence of operations involved in 
processing unit data and outputting picture and 
sound signals to a user"s display screen; 
FIGURES 31 and 32 depict illustrative first and sec- 
ond model software formats; 40 
FIGURE 33 depicts an illustrative memory map of 
RAM information contents including an object unit 
RAM information area and a game background 
related RAM area: 

FIGURE 34 depicts exemplary main CPU 228 and 
the game CPU 200 memory maps; 
FIGURE 35 is a flowchart delineating the sequence 
of operations performed by game CPU 200 and 
main CPU 228 during game fabrication processing; 
FIGURE 36 shows a unit pointer area for active so 
units and representative unit information for an 
identified active unit; 

FIGURE 37 shows a unit pointer area for all units 

which identifies exemplary unit data: 

FIGURE 38A and 38B is a flowchart showing how 55 

game program processing takes place using "unit 

work" table processing techniques; 

FIGURE 39 is an exemplary main table; 



FIGURE 40 is an exemplary "must" condition 
processing subroutine; 

FIGURE 41 shows an exemplary "Enemies Wipe- 
Out" condition subroutine; 
FIGURE 42 is an exemplary "unit action" table; 
FIGURE 43 is an exemplary "unit action" subrou- 
tine; 

FIGURE 44 is an exemplary "Go Next Stage" rou- 
tine: and 

FIGURE 45 is an exemplary "Go Ending" subrou- 
tine. 

DETAILED DESCRIPTION OF THE DRAWINGS 

Figure 1A is a general block diagram of a video- 
graphics/ video game program fabricating system in ac- 
cordance with an exemplary embodiment of the present 
invention showing the game processor system unit con- 
sole 2 and many of the associated input/output devices. 
The game processor system unit console 2 includes a 
floppy disk connection port 7 (which is shown in more 
detail in Figure 1 B) for receiving, for example, a 3.5 inch 
floppy disk 8. Floppy disk 8 stores "model software" in- 
cluding model game and operating system software. 
The operating system software, which is described in 
more detail below, controls the overall operation of the 
game processor system including controlling the trans- 
fer of game program related information to a memory in 
RAM cassette 4 out of which a game program is exe- 
cuted. The model software embodied on the floppy disk 
8 includes basic game program software which assists 
the user in game making and which the user modifies 
in fabricating his or her own video game design. It de- 
fines the fundamental genre of video games which may 
be generated, e.g., "shoot-em-up games", "role-playing 
games", "educational games", "simulation games", etc.. 
The floppy disk 8 may additionally contain system con- 
figuration data which is checked at boot-up to determine 
whether the system is in the proper configuration. 

At any time after the initial transfer of program in- 
formation from floppy disk 8 to a program RAM in RAM 
cassette 4, RAM cassette 4 may be removed from the 
game processor system unit console 2 and utilized in 
conjunction with a conventional video game system 
such as, by way of example only, the video game system 
commercially sold by the applicant as the Super Ninten- 
do Entertainment System. As will be explained further 
below in conjunction with Figure 24. the RAM cassette 
4 also includes a security processor of the type shown 
in applicants 

U.S. Patent No. 4.799,635. An exemplary security 
system which may be used in the present invention is 
described in further detail in the above identified appli- 
cation entitled "SECURITY SYSTEMS AND METHODS 
FOR A VIDEOGRAPHICS AND AUTHENTICATION 
GAME/PROGRAM FABRICATING DEVICE", Serial No. 
08/332,812 filed October 31, 1994, which application 
has been incorporated herein by reference. 
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The game processor system console unit 2 includes 
an insertion port 5 tor a game processor ID card 6. In 
an exemplary embodiment of the present invention, the 
ID card includes a security code which is compared 
against data stored at a predetermined location on flop- 5 
py disk 8. If the comparison results in a determination 
of authenticity, then data from floppy disk 8 may be suc- 
cessfully transferred to RAM cassette 4. Although floppy 
disk 8 contents may be copied, the user is only issued 
one ID card 6 to thereby provide a measure of security 
against counterfeiters. The ID card 6 may also contain 
the user"s photograph and/or other identification data. 

. The game processor system console unit 2 shown 
in Figure 1 A is designed to be coupled to a wide variety 
of input/output devices. It includes a jack for microphone ?5 
10 connection to enable the input of sound signals that 
may be used during game play. Additionally, the game 
processor system console 2 includes at least two player 
controllers 12 and 14, which may be of the type de- 
scribed in U.S. Patent No. 5,207,426. These controllers 20 
are utilized to control video game play on a user"s tele- 
vision screen by controlling moving object character 
movement and associated special effects in, for exam- 
ple, the manner typically utilized in commercial available 
SNES controllers described in the above-identified pat- 25 
ent. 

The game processor system console 2 additionally 
includes ports for connecting a conventional mouse 16 
and PC compatible keyboard 18. The mouse 16 and 
keyboard 18 are utilized in a manner which will be de- 
scribed in detail below by the user as graphic/user in- 
terfaces during the video game design process. The 
mouse 16 permits a user such as an elementary school 
child who is totally unfamiliar with game programming 
techniques to create a unique video game through the 35 
use of the icon driven system described herein. The key- 
board 18 permits game modification through input, for 
example, of game software instructions by more sophis- 
ticated users such as game programmers. 

The game processor system unit console 2 also in- 
eludes a connection port for a modem board 22. By way 
of example only modem 22 is a 9600 baud, half-duplex 
modem. The modem 22 permits the game processor 
system to be used in an on-line network described be- 
low. The system also includes an A/C adaptor 20 for pro- 
viding power to the system. 

The game processor system unit console 2, as will 
be described further below, includes two central 
processing units. One is primarily responsible for video 
game play control and a second is primarily responsible 50 
for game editing related tasks and for executing the op- 
erating system program for controlling the transfer of in- 
formation from the game processor disk 8 to RAM cas- 
sette 4. 

The system components shown in Figure 1A and ^5 
described above permit a user who is totally unfamiliar 
with video game program development to create a wide 
range of video games using model software stored on 



floppy disk 8. Through the use of the optional compo- 
nents identified in Figure 1A, the system may be ex- 
panded to more readily permit professional game pro- 
gram designers to create video games in a unique em- 
ulation system. In this alternative embodiment, the 
game processor system includes an expansion board 
24 which couples further I/O and other components to, 
for example, the operating system CPU within console 
2. As shown in Figure 1 A, various additional I/O compo- 
nents may be coupled to the system such as a scanner 
30, hard disk drive 28 or printer 26. Scanner 30 may be 
a conventional optical scanner and is utilized to scan a 
graphical image, digitize the image for storage in the 
game processor system unif's console memory system 
for use in a video game being designed, A user would 
then be able to access the stored image, add colors and 
modify the image. An SCSI interface may be embodied 
on expansion board 24 to permit coupling to an IBM 
compatible PC 27. 

Figure 1 B is a perspective view of the game proc- 
essor system console unit 2. The console 2 includes a 
power ON/OFF switch 1 1 and a reset button 9. The reset 
switch 9 permits resetting the entire system including 
the operating system executing CPU and the game 
CPU. The reset button 9 in addition to placing the game 
program executing CPU at a known initial state also 
serves to interrupt the operating system CPU to permit, 
for example, testing operations to be performed. As 
shown in Figures 1A and IB receptacles 5 and 7 are 
slots for receiving the game processor ID card 6 and the 
floppy disk 8, respectively. Both receptacles 5 and 7 
have associated recessed areas to permit a user to eas- 
ily grab and extract the respective ID card 6 or floppy 
disk 8. The floppy disk receiving mechanism is further 
described in the above identified copending application, 
Serial No. 08/332,81 2 filed October 31 , 1 994, which ap- 
plication has been incorporated herein by reference. As 
shown in Figure IB, the console unit also includes a flop- 
py disk eject button 3. Additionally, as shown in Figures 
1 A and 1 B, connectors 13, 17, 19, 21 and 23 are ex- 
posed to permit ready connection of microphone 10, 
keyboard 18, mouse 16, controller 12 and controller 14, 
respectively. 

Figures 2A and 2B are a more detailed block dia- 
gram of the game processor system shown in Figure 1 A 
and are an illustrative embodiment which specifies de- 
tails such as the number of connector pins, particular 
types of memory devices, etc. These and other imple- 
mentation details are set forth only as an illustrative ar- 
rangement of one of many possible alternative arrange- 
ments for implementing the invention and should not be 
construed as limiting the scope of the present invention. 

Figures 2A and 2B identically numerically label 
many of the same input/output devices shown in Figure 
1 A and show connections between the I/O devices and 
game processor system console 2 in greater detail than 
Figure 1A. The controllers 12, 14, keyboard 18 and 
mouse 16 are coupled to the game processor system 
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console 2 via a front board connector unit embodied on 
front board 197 of Figure 2B. The connector in turn, is 
coupled to 25 pin connector 191 on console 2. Micro- 
phone 10 is likewise coupled to the console"s 25 pin 
connector 1 91 via a microphone jack and a microphone 
amplifier which is likewise coupled to the front board 25 
pin connector. The microphone amplifier is controlled by 
a volume control on front board 197. 

ID card 6 is coupled to console 2 via ID card circuit 
board 185 having an ID card connector and an 8 pin 
connector which, in turn, is connected to the console at 
8 pin connector 1 90. RAM cartridge 4 is coupled to the 
console at 80 pin connector 189 via a 62 pin connector 
board 186 which includes a 62 pin connector for con- 
nection with game cartridge 4 and an 80 pin connector 
for connection to connector 189. The game processor 
I/O system also includes an LED board 187 having an 
LED display and a 3 pin connector which, in turn, is con- 
nected to 3 pin connector 188 on console unit 2. Reset 
switch 9 is coupled to permit resetting game CPU, 200. 
Modem board 22 is coupled to console unit 2 via modem 
slot 1 95. An SCSI board 24 is coupled to a console unit 
2 via extension slot 194. Floppy disk drive 199 which 
receives floppy disk 8 shown in Figure 1 A is coupled to 
console unit 2 via 34 pin connector 193 which, in turn, 
is coupled to floppy disk controller 240. 

Figure 2B includes interface board 198 which re- 
ceives AC power via an AC adapter 20 and a power jack 
that is coupled to the 30 pin card edge connector on 
board 198 which, in turn, is coupled to the console"s 30 
pin card edge connector 192. Interface board 198 also 
includes a DC to DC converter coupled to the power jack 
and to the 30 pin card edge connector. The 30 pin card 
edge connector of board 198 receives video, sync, and 
sound signals from console unit 2 and couples such sig- 
nals to standard television unit 15. 

Turning next to the internal two CPU architecture of 
the game processor system console 2, as can be seen 
from Figures 2A and 2B, the hardware includes a game 
program executing CPU 200 (SCPU) and associated 
system components and an operating system and edit- 
ing system main CPU 228 and associated system com- 
ponents to be described below. Additionally, console 
unit 2 includes gate array circuitry 226 through which a 
large part of inter-processor communication takes place 
and an associated superposition controller 216 for su- 
perimposing the editing and operating system video out- 
put onto the game program executing subsystem out- 
put. 

Turning first to the game program executing sub- 
system, the game program executing hardware in the 
presently preferred embodiment may be implemented 
by hardware currently being sold by Nintendo of Amer- 
ica as the Super Nintendo Entertainment System 
(SNES). The present invention, however is not limited 
to Super NES related game program executing systems 
but rather may be used with alternative game hardware 
implementations. The game program executing game 



CPU 200 may, for example, be a 65816 compatible mi- 
croprocessor The game CPU 200 is coupled to working 
RAM 202 which, for example, includes 1 mega bit of 
storage. The game CPU 200 is coupled via system data, 

5 address and control busses to picture processing unit 
(SPPU) 212 which, in turn, is coupled to video RAM 214 
which may, for example, include 51 2k bits of storage. 

The exemplary embodiment uses two picture 
processing units 212 and 224. PPU 21 2 includes circuit- 

10 ry for generating video game displays under the control 
of game CPU 200 and PPU 224 generates editing relat- 
ed video displays under the control of operating system 
CPU 228. Game CPU 200 has access to video RAM 
214 via PPU 212 during vertical and horizontal blanking 

IS intervals. Thus, game CPU 200 can only access video 
RAM 214 through PPU 212 at times other than during 
active line scanning when PPU 212 is accessing video 
RAM 21 4. PPU 224 generates a video display from vid- 
eo RAM 220. As shown in Figure 28, the output of PPU 

20 21 2 and the output of operating system PPU 224, are 
coupled to a user"s television 15 via superimpose con- 
troller 216 which, in turn, is coupled to an RGB encoder 
218 through the previously identified connectors to tel- 
evision 15. 

25 Game CPU 200 is also coupled to sound processor 
208 which is coupled to its associated work RAM 210. 
The sound processor 208 may comprise a commercially 
available sound chip to generate sounds associated 
with the video game program being executed. Game 

30 CPU 200 can only access work RAM 21 0 through sound 
processor 208. 

In addition to components founds within an SNES 
system, the exemplary embodiment additionally in- 
cludes a one mega bit monitor ROM 204 and a 256 bit 

3S monitor RAM 206. The monitor ROM contains program 
instructions which are executed by game CPU 200 to 
result in a transfer of control to the operating system 
CPU 228 for the performance of editing and information 
transfer functions. The monitor RAM 206 stores data as- 

40 sociated with such processing. 

The Super NES video game machine, which is rep- 
resented in part in block diagram form in Figures 2A and 
2B, has only been generally described herein. Further 
details regarding the Super NES including PPU 212 and 

45 PPU 224 (utilized by the operating system processor) 
may be found in U.S. Patent 5,327,158 issued July 5, 
1994 entitled "Video Processing Apparatus" which ap- 
plication is expressly incorporated herein by reference. 
Still further details regarding the Super NES may be 

50 found in U.S. Patent 5,291,189 issued March 1, 1994, 
entitled "Direct Memory Access Apparatus and Image 
Processing System and External Storage Device Used 
Therein" and in U.S. Application Serial No. 08/138,448 
filed October 20, 1993, which is a continuation of U.S. 

55 Application Serial No. 07/793,735 filed November 19, 
1991, entitled "Mosaic Picture Display Apparatus and 
External Storage Unit Used Therefor" which applica- 
tions are herein incorporated by reference. 



6 



<EP 07131 74A1 I > 



11 EP 0 713 174 A1 12 



The game processor system console 2 also in- 
cludes an operating system or main CPU 228 which may 
be, for example, a NEC V810 processor which is a 32 
bit RISC processor Alternatively, for example, a Motoro- 
la 68000 Series Processor or other processors having s 
similar processing power may be utilized. The main 
CPU 228 processes operating system related routines 
in parallel with the game CPU 200 which executes a vid- 
eo game program, as will be described further below. 
Main CPU 228 and game CPU 200 communicate io 
through gate array 226 which is described in detail in 
conjunction with Figure 23, As indicated above, proces- 
sor 228 (like game processor 200) includes an associ- 
ated picture processing unit 224 for performing graphic 
processing operations to reduce the graphics process- ^5 
ing burden on CPU 228. The operating system CPU 228 
is coupled directly to video RAM 220 or indirectly via pic- 
ture processing unit 224 depending upon the control set- 
ting of bus selector 222. As noted above, PPU"s 212 
and 224 are of the type described in the above identified 20 
SNES related patents and patent applications which 
have been incorporated herein by reference. 

In accordance with the presently preferred embod- 
iment of the present invention, main CPU 228 is a proc- 
essor having a 32 bit bus width and operates at a 21 .477 25 
MHz clock rate . The CPU 228 is coupled to, for exam- 
ple, a 4 megabyte DRAM 230. The work DRAM 230 is 
expandable, if desired, to up to 24 megabytes via an 
extension DRAM 232. Main CPU 224 is additionally cou- 
pled to, for example, an 8 mega bit ROM 234 which 30 
stores an initial program loader (IPL) subroutine a BIOS 
operating system program, and character fonts to be ac- 
cessed by CPU 228. CPU 228 also has access via its 
system bus to an 8 mega bit flash memory 236 which is 
utilized, for example, for software backup for data from 3S 
floppy disk drive 1 99. The main CPU 228 system bus is 
also coupled to, for example, a 1 0 bit A/D converter 238 
(which is utilized to digitize sounds coming from, for ex- 
ample, microphone 1 0 via board 1 97), a floppy disk con- 
troller 240 and real time clock 242. -^o 

The main CPU 228 and the game CPU 200 boot up 
independently. After power is turned on, the game CPU 
200 is initially placed in a reset state and then restarted. 
Initially, the game CPU 200 executes program instruc- 
tions out of monitor ROM 204. The main CPU 228 con- -^5 
trols the areas of memory which are accessed by game 
CPU 200. The main CPU 228 loads a register in gate 
array 226 which identifies whether CPU 200 is to exe- 
cute out of monitor ROM 204 or RAM cartridge 4. The 
main CPU 228 executes the initial program loading and so 
operating system instructions in ROM 234 to read out 
the contents of floppy disk 8 including the model game 
software via floppy disk drive 199 and floppy disk con- 
troller 240. Operating system program instructions for 
controlling operations associated with the model game 55 
software are transferred to DRAM 230 for execution by 
main CPU 228. After system power has been turned off 
and thereafter turned on, main CPU 228 checks flash 



memory 236. Upon being first turned on, operating sys- 
tem programs are read out from floppy disk 8 and stored 
in flash memory 236 and transferred to DRAM 230. 
Upon being turned on for the second time, operating 
system programs are transferred from flash memory 
236 to DRAM 230 without use of the floppy disk 8. In 
general, the flash memory"s access speed is faster than 
the floppy disk"s access speed. Therefore, the system 
can be quickly started at the second turn on. 

Model software information from floppy disk control- 
ler 240 is initially buffered in DRAM 230 for transfer to 
the RAM cartridge 4. Main CPU 228 then generates a 
communication ready signal and transmits the signal to 
a handshake port in gate array 226. Game CPU 200, 
through instructions stored in monitor ROM 204, moni- 
tors the handshake port and prepares for reception of 
data and/or instructions from the communication RAM 
in gate array 226. The handshake port may be illustra- 
tively implemented by a pair of one way handshake 
ports. A one way handshake port communicates infor- 
mation from the Main CPU 228 to Game CPU 200. An- 
other one way handshake port communicates the infor- 
mation from the Game CPU 200 to Main CPU 228. 

The handshake port includes a buffer register which 
is addressable by game CPU 200 which indicates 
whether information is to be transferred between main 
CPU 228 and game CPU 200. When game CPU 200 
has determined that a communication RAM embodied 
within gate array 226 has received information from 
main CPU 228, game CPU 200 accesses the informa- 
tion from the communication RAM and transfers such 
information to RAM cartridge 4 via 80 pin connector 189 
and connector board 1 86. The main CPU 228, after the 
communication RAM information has been transferred 
to RAM cartridge 4, sets a register embodied within gate 
array 226 which initiates switching of control of game 
CPU 200 from monitor ROM 204 to RAM cartridge 4. 
After the game CPU control has been switched to RAM 
cartridge 4, game CPU 200 no longer monitors the 
handshake port or has any further interaction with the 
communication RAM within the gate array. At this point, 
game CPU 200 operates to execute game related in- 
structions out of RAM cartridge 4 in a manner substan- 
tially the same as the applicants game machine de- 
scribed in the above identified SNES related patents 
and patent applications. 

The main CPU 228 constantly monitors information 
transmitted via the CPU 200 system bus by accessing 
a register copy RAM embodied within gate array 226. 
The information written into the register copy RAM from 
the game CPU 200 bus is formatted such that it"s com- 
patible with the main CPU 228 format. Information from 
PPU 212 and sound processor 208 flows into the regis- 
ter copy RAM for monitoring by main CPU 228 such that 
main CPU 228 is continuously aware of the game state. 
The use of a 32 bit RISC processor provides main CPU 
228 with the processing power necessary to monitor 
such a large volume of information. As is described be- 
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low, both the images generated by main CPU 228 via 
its PPU 224 and VRAM 220 and game CPU 200 via its 
PPU 212 and VRAM 214 are simultaneously displayed 
on the user's television 15 through the use of a super- 
impose controller 216 which is in part resident in gate 
array 226 and is described in detail below. 

The main CPU 228 is continuously aware of game 
CPU 200 operations so that it will not initiate a user com- 
manded "system break" to modify game play until all re- 
quired information is written into VRAM 214 for display 
operations. A system break logic circuit regulates the 
timing for generating a game break control signal to 
game CPU 200 when the system break command is ex- 
ecuted. Thus, main CPU 228 monitors data on the game 
CPU bus, particularly information relating to generation 
of video display or sound to determine an appropriate 
point in time to execute a system break to thereby avoid 
distorted picture and sound information. 

Figures 3A and 3B are partial memory maps of cer- 
tain of the memory devices shown in Figure 2A and 28 
after the transfer of information from the floppy disk 8 to 
the RAM cartridge 4. The model software stored on flop- 
py disk 8 includes a control file, model game related da- 
ta, unit pointer, address data and a main game program 
(as well as sound data, not shown, which is coupled to 
sound processor 208). As can be seen from Figure 3A, 
not all such model software is transferred to RAM car- 
tridge 4, rather, DRAM 230 maintains a control file which 
stores data relating to the changing game conditions as 
selected by the user as well as editing (e.g., Mario Fac- 
tory) and operating system software. When the model 
software is executed, the Unit Work data is generated 
by the main program of the model software. After a "sys- 
tem break" is initiated by the user to stop game play to 
modify a model game, unit work data, unit pointer and 
DATA for editing are transferred to a buffer area. When 
the editor using the control file is finished, the modified 
information (DATA and Unit Pointer information to be de- 
scribed below) is stored in the buffer area data and then 
transferred to RAM cartridge 4 which also stores the 
game main program. 

The game processing system of the present inven- 
tion is designed for use in various network configura- 
tions. The present invention contemplates "friend net- 
working", i.e., an exchange of RAM cassettes 4 storing 
newly generated video games among users. Similarly, 
an ID card 6 and a floppy disk 8 may be carried to the 
house of a friend for use with a RAM cassette 4 in an 
identical game processing processor system. 

Additionally, as shown in Figure 4, an on-line net- 
working system is also contemplated. As shown in Fig- 
ure 4, game information may be transmitted via modem 
22 shown in Figure 1A over telephone lines 43 from a 
user"s house 48 through an access point 42 to a game 
processor center 40 via a digital link 47. Similarly, game 
information may be transmitted from the house 50 of a 
friend via a telephone line 43 to an access point 44 and 
then to game processor center 40 via digital link 47. 



Game information may also be transmitted from the 
game manufacturer (such as, for example, Nintendo) 
46. In the on-line networking system shown in Figure 4, 
it is possible to readily supplement the model software 

5 embodied on a user"s floppy disk 8 to add to the model 
video game software to be modified. 

In accordance with one exemplary embodiment of 
the present invention, the model software stored on the 
floppy disk 8 includes a portion of the video game de- 

10 signed by a manufacturer which a user cannot change. 
This portion of the model software is referred to as the 
"base file". The "user file" is the portion of the video 
game that a user can change. In the system shown in 
Figure 4, the user file may be transmitted via the network 

15 to the house of a friend having a game processor system 
to permit interactive game play between users or to per- 
mit a friend to play a modified version of a newly de- 
signed game. The access points 42 and 44 are provided 
to, for example, minimize the telephone charges asso- 

20 ciated with transmitting a game over extremely long dis- 
tances. The game data would then be relayed to the 
game processor center 40 via direct digital links 47. The 
game data after being received at the game processor 
center 40 is thereafter retransmitted to the appropriate 

25 destination. 

Prior to describing the game processor unit system 
hardware and software in further detail, the game fabri- 
cating and editing operations embodied in the illustrative 
embodiment will next be described. After floppy disk 8 

30 is inserted into console receptacle 7 and game proces- 
sor ID card 6 is inserted into receptacle 5, a title screen 
is displayed such as the exemplary screen shown in Fig- 
ure 5 entitled "Mario Factory". The title screen shown in 
Figure 5 shows five icons which may be selected by a 

35 user via mouse 1 6. Icons are selected by "clicking", i.e., 
lightly pressing, the left mouse button. Although five 
icons are shown in Figure 5, it should be appreciated 
that the following description is an illustrative embodi- 
ment which exemplifies one of many possible imple- 

"to mentations. For example, more or less than five icons 
may be displayed on the title screen and different func- 
tions may be selected in addition to, or in place of, those 
shown in the illustrative embodiment. 

The title screen shows a "load model software" icon 

45 which, if selected by mouse 1 6, results in the model soft- 
ware stored on floppy disk 8 being loaded into console 
unit 2 memory in a manner described in more detail be- 
low. Figure 5 also includes a "game icon" in which the 
game embodied in the model software may be selected 

50 for execution and modification to create a new and rad- 
ically different game from that embodied in the model 
software. The title screen shown in Figure 5 also in- 
cludes a network icon which enables selection of mo- 
dem 22 for transmission of data to a destination via tel- 

55 ephone lines. Additionally, disk save and editing tool 
icons may be selected. 

If the game icon shown in Figure 5 is clicked, a 
game program initiation screen will typically be dis- 
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played. After a user selects whether the game is to be 
played by one or two players, a user depresses the start 
button of controller 12 or 14 shown in Figure 1A. The 
game specified by the model software, e.g., a version 
of the well known "Mario Bros." game, then begins play. 

At any point in the game in which the user desires 
to change any displayed moving object character or any 
portion of the display screen background, the user stops 
the game to initiate what is referred to herein as a "sys- 
tem break". When a system break is initiated, as shown 
in Figure 6, the system break screen is displayed in 
which a system window screen 50 is superimposed over 
a user selected game screen 57. A moving object char- 
acter, such as the well known "Mario" prominent in video 
games manufactured by the applicant , or any portion 
of the background may be modified by clicking on the 
area where a change is to be made. 

The present invention permits wide ranging chang- 
es to the model software such that the model software 
game background and moving objects are modified to 
the extent that the original model software game is un- 
recognizable. By way of example only Figure 6 illus- 
trates that a change is to be made to the moving object 
character recognizable as "fVlario" by the user "clicking" 
the mouse when the cursor (e.g., the hand) overlays the 
character to be modified. If desired, a completely new 
character may be substituted for Mario. 

For the purposes of this example, presume that a 
user playing the game wishes to remove Mario"s mous- 
tache. As noted above, a user stops the game by initi- 
ating a system break upon clicking the mouse. There- 
after, the user clicks on Mario. Main CPU 228 generates, 
for example, a rectangular block circumscribing the 
character to be changed together with an indication 52 
of the character"s "unit number" . Each of the moving ob- 
jects and background portions of the game which may 
be modified are identified by unique unit numbers. As- 
sociated with each unit number and its object, as will be 
described in detail below, are a wide range of charac- 
teristics such as, for example, size, poses, animation 
paths, etc. The system window 50 includes a series of 
icons which permit the user to select a wide range of 
editorial functions. The system window "stage" icon 54 
enables access of the "stage" window shown in Figure 
18 which permits a vast range of background character 
editing. The system window also includes a return to the 
title screen icon 55, a reopen game icon 59, and a 
switchable control 53 which permits the user to switch 
between a game stop and slow play mode. Numerous 
additional or alternative editing functions could be in- 
cluded in the system window 50, if desired in the system 
window 50 to identify particular game fabrication/editing 
tools which may be selected. 

As can be seen in Figure 6, system window 50 and 
its editing tool indicating icons as well as unit number 
indication 52 are superimposed on game screen 57. The 
selection of the Mario character for editing results in the 
display of a sequence of Mario editing screens/win- 



dows. Other moving objects may be selected for editing 
in a similar manner. 

Figure 7 depicts an exemplary character editing 
screen. It shows a Mario character editing related win- 

s dow which visually indicates that it is the Mario character 
being modified (60). Below the indication of Mario, the 
current status of Mario is identified (62). The status of 
"Mario" is indicated as being "stopped". Other exempla- 
ry status indications which could have been identified 

10 are Mario "moving left", a Mario "moving right", a Mario 
"jump" indication or a Mario appearing from the top or 
bottom. By changing the status of Mario, which may be 
done using the status editors described below, the game 
is changed accordingly. 

75 Below the status block, a sequence of icons are 
shown indicating exemplary Mario related editorial mod- 
ifications which may be made and editing screens which 
may be accessed by clicking on the related icon. Icon 
64 enables changes to be made with respect to the 

20 Mario animation patterns as described below in con- 
junction with Figure 10. Icon 66 permits editing of char- 
acter "status" conditions as described below in conjunc- 
tion with Figure 1 7. Icon 68 permits changes to be made 
to the special sound effects associated with the video 

25 game when Mario is moved. Icon 70 resumes game 
play. Icon 72 permits changes to be made to the "all sta- 
tus" conditions as described below in conjunction with 
Figure 9. Icon 74 enables changes to be made with re- 
spect to the Mario character dot pattern as described 

30 below in conjunction with Figure 8. Icon 76 permits ed- 
iting of character movement as described below in con- 
junction with Figure 16. Icon 78 causes the system to 
return to the system window. 

For example, to remove Mario"s mustache, a user 

3S clicks on character icon 74 to generate the display 
screen shown in Figure 8. By clicking on the character 
icon, control is transferred to the character design tool 
shown in Figure 8. A zoom topi may be selected by click- 
ing on icon 85 which results in an expanded view of the 

^0 character to be modified. A pencil tool may be selected 
by clicking on icon 86 which switches to pencil mode/box 
mode. Pencil mode permits changes of the graphic data 
on a dot by dot basis. Box mode permits the graphic 
data to be painted by any square area. Icon 84 controls 

^5 resuming game play or returning to the system break 
screen. An erase tool may be selected by clicking on 
icon 87 which erases all graphic data on a pattern of, for 
example, Mario. An undo tool may be selected by click- 
ing on icon 88 which cancels the immediately preceding 

50 command. As shown in Figure 8, a color palette 80 is 
displayed to permit a user to select any of a number of 
colors to change the color of any portion of Mario by 
clicking on a selected color and drawing on Mario with 
a coloring tool (e.g., crayon shaped cursor) in accord- 

55 ance with conventional painting programs. This color 
palette function enables a user to select colors within a 
given color palette, select between various palettes of 
color and create new colors with a color spectrum func- 
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tion. 

Each of the moving objects associated with the 
model software has a predetermined number of different 
poses. By way of example only, the Mario pattern is 
structured with a total of thirteen pose patterns. The pat- 
tern number is indicated in the left hand portion of the 
screen shown in Figure 8 (82). The pattern number zero, 
for example, is selected by clicking on the "0". When the 
pencil mode is selected by clicking icon 86, a crayon 
shaped cursor can be used to erase Mario"s moustache 
in pattern number zero and replace it with Mario"s skin 
color on color palette 80. Similar operations are per- 
formed with each of the remaining Mario patterns 1 
through 12. 

Once all of the moustaches have been eliminated, 
for example, robot icon 84 is clicked to generate a return 
to the system window, where the game icon may be se- 
lected to resume game play. When game play is re- 
sumed, Mario will be displayed throughout the game 
with no moustache. Using the display screen shown in 
Figure 8, each individual pixel of the Mario pattern may 
be modified by the user Using the various editors avail- 
able in the system a user can create an original Mario 
and control a wide range of animation and other opera- 
tions performed on this or any other character 

Figure 9 shows an illustrative "all" status screen ed- 
itor display for the unit named "Mario". As noted above, 
each moving object or other modifiable character is 
identified by a unit name. Each unit name, in turn, has 
an associated collection of statuses. The present inven- 
tion utilizes an "all status" editor which identifies the sta- 
tus of a character and permits operations to be selected 
by a user to result in a status modification. Thus, as 
shown in Figure 9, for the unit name 90, i.e., Mario, there 
are various identified statuses such as "stop", "move 
left", "move right", "slide left", "slide right", "jump", "fall", 
"scrunch", etc. (92). Additionally, there are tools 94 for 
copying or erasing a status. The identified statuses 92 
inform the operating system CPU 228 of the condition 
of an object as it is manipulated by the game executing 
CPU 200. For each status, the system CPU 228 is in- 
formed of the operations associated therewith via a con- 
trol file data structure shown in Figure 3A. Thus, for each 
status, a sequence of associated operations are identi- 
fied and stored. For example, for status 5 which is "jump- 
ing", the data structure stores an indication of the sound 
generated during the jumping (e.g., "boing"), the move- 
ment during jumping (e.g., an animation path identified 
by the animation program) and the programming during 
the jumping operation (if Mario hits the floor, then the 
character will die). 

The status index on the left hand portion of Figure 
9 permits accessing a more detailed sequence of oper- 
ations associated with the status. For example, as 
shown in Figure 9, if the status 1 entry is selected by a 
user In the right hand portion of Figure 9, the animation 
for the status is displayed. Additionally, the sound effect 
associated with the status is generated and appropriate 



entries under the KEY, AUTO, SE, and ANIME entries 
are displayed. As indicated in Figure 9 the "KEY" entry 
identifies whether for the particular status, the active 
controller is for player 1 or player 2 and which button is 

5 the active button. If the "KEY" icon is selected, a key 
editor is utilized as described below in conjunction with 
Figure 9A. The "AUTO" entry indicates the state of the 
autoprogrammer which is described in Figure 1 6 for the 
identified status. SE and ANIME identify sound effects 

10 and animation, respectively. Also, background music 
BGM can be selected with an SE entry. 

If the game is stopped and the user clicks on Mario, 
the system CPU 228 accesses the control file corre- 
sponding to the status indication in Figure 9 and thereby 

'5 knows which selected sequence is to be associated with 
the identified status. In this fashion, the information as- 
sociated with the particular screen at the identified game 
stage is transferred to the system CPU 228. 

Any key function status may be controlled by a key 

20 editor described in Figure 9A. A key editor defines the 
status related to controller 1 or 2, any button on the con- 
troller and/or the button condition such as when the but- 
ton is pushed (one time) or while the button is pushed 
(continue). As shown in Figure 9A, the key name indi- 

25 cator permits setting up major types of keys (e.g., 8) by 
key name. A rename button permits altering the key 
names. A game option name permits choosing an option 
from a menu like the status editor. A Key condition indi- 
cator causes game options to be executed only when 

30 these key conditions are matched. A 1 P/2P icon permits 
selecting 1 P or 2P controller when you click this icon. A 
controller indicator permits selecting the "KEY" or 
"KEYS" when you click the button. 

If animate icon 76 is selected in Figure 7, an anima- 
ls tion editor is selected so as to result in the display of an 
animation screen such as, for example, shown in Figure 
10. Figure 10 shows a moving object in the form of a 
crab in various poses creating an animation sequence, 
where each pose is assigned a pose number As will be 

•^0 explained further below in conjunction with Figure 16, 
an "autoprogrammer" tool is utilized to define a path 
over which movement occurs. 

The animation tool shown in Figure 1 0 defines a se- 
quences of poses. In the present illustrative embodi- 

^5 ment, eight poses may be defined in an animation se- 
quence. Figure 1 0 shows areas for four of the eight pos- 
es (labelled pose numbers 0 through 3) in the animation 
sequence to be displayed on a screen. The user may 
also define the time for which each cell is to appear by 

50 using the controls 102. If the cell time indicator 104 is 
set at 60, then the individual cell is displayed for one 
second. The overall tempo of the sequence can be con- 
trolled by modifying the tempo control 106. In the 
present illustrative embodiment, the standard speed for 

55 the tempo is set at zero. The tempo can be controlled 
by setting a negative number to create a slower tempo 
or to a positive number to create a faster tempo. If game 
play is renewed, the individual cell display frequency 



10 



BNSDOCID!<EP 07iai74A1 I > 



19 



EP 0 713 174 A1 20 



and the animation sequence tennpo are controlled 
based on the settings of Figure 10. 

Poses 8 through 1 5 shown in Figure 1 0 (collectively 
108) identify alternative poses which may be inserted in 
the animation sequence. A userneed only click on a par- 
ticular pose, e.g., 10, drag the pose and place it over 
for example, animation sequence pose 2. This will result 
in pose 10 being displayed in place of pose 2. 

The area defined by four corner marks shown in the 
upper lefthand corner of Figure 10 represents the colli- 
sion threshold 109 for the particular character i.e., dur- 
ing game play a collision will be detected if the identified 
character appears within the distance indicated by the 
corner mark area to another object. The corner mark 
area size may be controlled by the "HIT" indicator con- 
trol threshold control 112. 

Turning back to Figure 6, if, after a system break 
has been initiated, the user clicks on the stage icon 54 
on system window 50, the stage window shown in Fig- 
ure 18 is displayed on the screen. A "screen editor" is 
accessed such as shown in Figure 11 by clicking on the 
screen icon 152 on the stage window. Using the screen 
editor if desired, a background element from the bottom 
portion of Figure 11 may be dragged up to the back- 
ground screen portion to modify the actual display back- 
ground. The screen editor permits the user to review and 
modify any one of a number of different background lay- 
ers associated with the game at the point in time of the 
system break. The screen editor includes controls for 
horizontally and vertically scrolling the background to 
permit the user to view the entire background through a 
user accessible "view" mode which permits selection of, 
for example, a first, second or third background screen. 
Through the screen editor each of the different back- 
ground layers are accessible and scrolling may be con- 
trolled to view the entirety of each of the background 
layers as well as to modify each layer 

The screen editor also has an associated "map ed- 
itor" which may be opened such as that shown in Figure 
12. The map editor is available to relocate available 
background screens which are shown in a reduced form 
in the map editor Using the map editor "pasting" func- 
tion, the background of the game display screen may 
be modified by, for example, dragging a background 
screen drawing a character such as indicated at 120 in 
Figure 13 and pasting it onto an active background. 

The music associated with the video game back- 
ground may be modified by accessing the music editor 
by clicking on a musical symbol icon associated with a 
"STAGE" window, which will be described further below, 
to result in a screen display such as shown in Figure 1 4. 
As indicated in Figure 14, the music editor displays a 
game music sheet. The "switches" (which, during music 
edit, are displayed in color) correspond to similarly color- 
ed figures on the game music sheet display. By select- 
ing, via the mouse, one of the displayed switches shown 
in Figure 1 4, it is possible to playback only the bass por- 
tion of the music, the piano portion of the music or any 



other instrument that is selected. By selectively layering 
the bass, piano and other musical sounds, the back- 
ground music is formulated. 

If a colored symbol is clicked in Figure 1 4 identifying 

5 a selected musical segment, the window shown in Fig- 
ure 1 5 is generated and overlayed on the musical editor 
screen of Figure 14 to thereby permit individual control 
over musical tone, sound volume, etc. for each selected 
numerical segment. For example, if the "KEY" control 

10 shown in Figure 1 5 is manipulated, the background mu- 
sic key will change as the mouse is moved to drag the 
key control to a different setting. Similar control may be 
exercised over "echo", "tempo", "pan" and any other de- 
sired aspect of the background music. The "pan" control 

?5 permits manipulation of the left/right stereo balance. 

In addition, the music editor of the present invention 
permits the music to be changed in real time while the 
music is being played back. If a play symbol is clicked 
in Figure 14, the background music is played and the 

20 window shown in Figure 1 5A is generated. The window 
is used to change "music volume", "tempo", "echo" and 
"key" in real time with playing music. For example, if the 
"key" icon is clicked, a control bar such as a key bar in 
Figure 15, is generated and real time control may be 

25 exercised. 

The original model software includes a predeter- 
mined number of original sound waveforms associated 
with the game, e.g., 32. The user is able to assign the 
original sound waveform to eight sound courses and se- 

30 lectively modify any aspect of the sound courses using 
the musical editor A figure identifying each sound 
course on the sound sheet may be displayed by a 
unique mark associated with each original sound wave- 
form. The musical editor software continually checksthe 

35 state of each of the icons shown in Figure 1 5A and mod- 
ifies the output music accordingly. In addition, the sam- 
pling waveform recorded from microphone 10 can be 
added to the original sound waveform list. 

The game processor system additionally includes 

•to an "auto programmer" feature by which movement of an 
object may be modified by the user An exemplary dis- 
play explaining the operation of the auto programmer is 
shown in Figure 16. The auto programmer is accessed 
by clicking on the auto programmer icon 76 in Figure 7 

^5 or via the auto programmer icon associated with the "all 
status" editor of Figure 9. Initially, a unit such as the 
character shown in Figure 1 6 is selected by pressing the 
left mouse button. Using the mouse, a path containing 
up to 64 movements indicated by dots can be stored. If 

50 the left mouse button is depressed while the mouse is 
still moving along a path the entire path is stored. If the 
dots are disposed such that they are close together the 
movement is slow. If the dots are further apart, the 
movement is faster. The speed of movement, however 

55 can be further adjusted by the use of a tempo control 
shown in Figure 16. Figure 16 has an associated play 
or stop control in which a path can be played back or, if 
desired by the user, stopped and the path thereafter al- 
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tered. By using a "sound effect" button 1 30 and the step 
control bar shown in Figure 16, sounds may be associ- 
ated with an objecf's movement. For example, a "bang- 
ing" sound can be associated with an object reaching a 
peak in a path. By holding the step button the object may 
be moved to the point where sounds are to be added. 
The clicking of the "sound effect" button associates the 
selected sound with a point in the path to which the ob- 
ject has been stepped. 

The game processor system also includes a "sta- 
tus" editor. If during game play, a system break is initi- 
ated when, for example, the character Mario is jumping, 
the Mario window shown in Figure 7 is accessed. If "sta- 
tus editor" icon 66 is selected at this point and time, then 
a display screen such as shown in Figure 17 results. In 
Figure 17, for the character Mario hav:;--. a status of 
"jumping", a status screen is shown hav.-vj a first col- 
umn 140 and a second column 142. The column 140 
includes rows which define a sequence of conditions. 
The conditions specify, for example, whether Mario 
reaches a particular height in a jump. Column 1 42 iden- 
tifies for each condition a result related process that oc- 
curs if the condition is detected. For example, if Mario 
reaches a certain height in a jump, then Mario may, for 
example, disappear. The status editor permits the user 
to change the conditions and/or the results. For exam- 
ple, the user may change the result which flows from 
Mario reaching a certain height in a jump from "Mario 
disappears" to, for example, "nothing happens". Then 
when the game is resumed, the modified process will 
be performed when the condition is detected. The status 
editor shown in Figure 1 7 also permits creation of a new 
process by those familiar with video game programming 
language instructions via keyboard 18 shown in Figure 
1 . If a process on the column 142 is clicked, a process 
list is generated on the screen. Any listed process can 
be selected to be modified. If a process on the process 
list is clicked, the process program of the process can 
be modified with video game program language. The 
video game program language instructions are com- 
piled automatically and stored as a new process on the 
process list. 

This direct input of game program language instruc- 
tions, which are similar to BASIC instructions, is expect- 
ed to be utilized by advanced, sophisticated game de- 
signers. Such game programming language instruc- 
tions may alternatively be used by an advanced game 
designer who does not chose to begin game design 
starting with model software based on a known genre 
of games. Such a sophisticated user may use the key- 
board to, in effect, create his or her own original model 
software and use the features described herein to mod- 
ify the user"s created original game. 

Turning back to Figure 6, as noted above, the sys- 
tem window 50 includes a stage icon 54. The stage icpn 
opens the stage window shown in Figure 18 below. 
Stage window Indicator 150 displays the current stage 
number and the status name such as for example, "dur- 



ing game". Icon 152 is the screen button which, as pre- 
viously described, permits editing of the current back- 
ground. The map icon 1 54 as previously described, per- 
mits changing the current background map. Selection 

s of icon 156 labelled "BGM" results in editing the current 
background music. The status icon 158 accesses the 
status editor to change the programming as described 
above of the current stage. Icon 1 60 returns back to the 
system window shown in Figure 6. Icon 162 resumes 

10 game play and icon 164 displays the current stage 
number and a current status name. 

Figures 19 through 21 summarize the manner in 
which the game modifying/editor display screens, de- 
scribed above in conjunction with Figures 5 through 18, 

IS may be accessed beginning with the "Mario Factory" 
screen. Figure 19 is a functional representation of the 
Mario Factory title screen shown in Figure 5. The file 
icon, shown in Figure 1 9, indicates the selection of a file. 
If the user clicks on the "tool box" icon, the tool box select 

20 screen and its editorial features functionally represented 
in Figure 20, may be accessed. By clicking on the 
"game" icon, the model software related editorial fea- 
tures shown in Figure 21 , may be accessed. If the "con- 
figuration" icon is clicked, the user may change either 

2S the mouse or keyboard configuration. By clicking on the 
network icon, model software and/or user files (indica- 
tive of modifiable portions of the game) may be trans- 
mitted to or received from other users via modem 22. 
Figure 20 identifies the editing related tools acces- 

30 sible through the "tool box" selection screen. By access- 
ing the tool box screen, game play may be changed out- 
side of the context of the game. In this fashion, a user 
may not need to play the entire game to change any 
particular character or any aspect of the game desired. 

3S Instead, the user may go directly to the data and change 
it. Through the use of the tool box which is accessed 
from the Figure 5 Mario Factory title screen by clicking 
on the tool box icon, an advanced user may make many 
detailed changes to the game without making the 

40 changes from the context of the game itself. The "From 
Author" block indicates that the author may transmit a 
message via the network, for example, describing the 
details of a transmitted game program. The "map col- 
lection" block indicates the ability to collect various 

-^5 background maps and to edit those maps with the 
screen editor, unit screen editor and map editor The unit 
screen editor is accessed to dispose the units to the po- 
sition indicated on the map. Usually, the unit screen ed- 
itor is accessed by clicking on the "unit" icon on the map 

so editor as shown in Figure 21. At the tool box selection 
screen, the unit screen editor is accessed directly from 
the map collection menu. 

Through the "tool box" select screen, a "program 
collection" feature may be accessed to receive an as- 

55 sembler listing, a basic listing and an auto programmer 
listing. The basic listing and the auto programmer listing 
may be edited by the program editor and the auto pro- 
grammer respectively. 
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A "unit collection" feature may be utilized to access 
a unit list identifying the various units that exist through- 
out the game, The unit list may be edited by the all-status 
editor. The list connpiles all units which are registered 
within the game program. The tool box screen addition- 
ally permits access of a sound collection feature which 
provides access to a background music list which may 
be edited by the music editor and a special effects (SE) 
list which may be edited by the special effects editor. 

The tool box select screen also permits access to a 
"game structure" collection feature. These features typ- 
ically apply to the entire game and go beyond individual 
unit applicability. For example^ a "game structure" fea- 
ture may identify how many times a particular character 
may die before the game ends. This characteristic is set 
during game structure editing. In regard to the "game 
info" feature, game structure in this category may iden- 
tify how many green turtles may appear in the game or 
what the first screen level may be. Such information may 
be edited via the data editor. The stage list game struc- 
ture information relates to various game sequences 
which are available. Stage list information may be mod- 
ified via the status editor the program editor or the data 
editor. 

Figure 21 identifies editorial/game fabricating 
changes that can be made during game play. After a 
system break is initiated, as described in detail above, 
a user may access editors by selecting, for editing, a 
moving object unit or by selecting a stage icon for chang- 
ing the background. The various editors which are 
shown correspond to the icons associated with the var- 
ious screen displays. For example, the animation editor 
dot editor auto programmer, special effects editor all- 
status editor key editor status editor program editor 
and data editor are accessible using the icons shown, 
for example, in Figure 7. Similarly the stage or back- 
ground related editors such as the music editor status 
editor screen editor unit screen editor map editor and 
data editor are associated with the stage window related 
icon shown in Figure 18. As shown in Figure 21 in the 
exemplary embodiment, the unit screen editor may be 
reached by accessing first either the screen editor or the 
map editor The editors which are accessed via other 
editors are typically those which are utilized less fre- 
quently by, for example, more advanced game develop- 
ers who may use a program editor to actually change 
game program language instructions. 

The editors identified in Figures 20 and 21 operate 
in the manner described in conjunction with Figures 5 
through 18. For example, the auto programmer editor 
shown in Figures 20 and 21 provide the ability to edit 
object movement as indicated on the display screen 
shown in Figure 16. The status editor identified in Fig- 
ures 20 and 21 operates in the manner described in con- 
junction with the screen display of Figure 17. The ani- 
mation editor identified in Figures 20 and 21 operates 
as described in conjunction with Figure 10. The all-sta- 
tus editor identified in Figure 21 operates as previously 



described in conjunction with the display screen of Fig- 
ure 9. 

Turning back to the hardware associated with the 
illustrative embodiment of the present invention, Figure 

5 22 shows a more detailed block diagram of the gate ar- 
ray 226 shown in Figure 2A. The gate array 226 is re- 
sponsible for controlling a variety of functions including 
superimposing the video signals output from CPU 228 
and game CPU 200, game processor debugging related 

10 functions (hardware and software breaks, address, data 
traps, etc.) as well as a variety of interface functions 
(such as game CPU 200/main CPU 228 interface con- 
trol: game hand controller interface and mouse, key- 
board and ID card interface), The gate array 226 also is 

75 involved in CPU 228 bus access control, interrupt con- 
trol, CPU 228 ready control: DRAM control including 
control of the control bus, address multiplexing, refresh 
control and peripheral LSI access control including con- 
trot of the ROM 234, flash memory 236, floppy disk con- 

20 trol 240, etc. 

As shown in Figure 22, the gate array interacts with 
various components shown in Figures 2A and 2B includ- 
ing CPU 228, CPU 200, PPU 212, etc. Address decoder 
260 is coupled to the address bus of GPU 228 and gen- 

25 erates chip select signals to other devices associated 
with CPU 228. As can seen in Figure 22, address de- 
coder 260 receives various clock (CLK), control signals 
(R/W), timing signals (BCYST) and generates the chip 
select signals for selecting the A/D converter 238, flash 

30 memory 236 and other components on the main CPU 
228 as well as other gate array components. 

Gate array 226 additionally includes memory con- 
troller 262 which is coupled to the CPU 228 address bus 
for generating address and other controls signals for 

35 controlling DRAM 230 and for generating various 
read/write signals associated with CPU 228. The mem- 
ory controller 262 is responsive to clock, timing and con- 
trol signals from CPU 228 to generate DRAM addresses 
MAGI through MA10, row and column address signals 

40 for the DRAM 230, a write signal for the DRAM 230 and 
I/O read and I/O write control signals. 

Gate array 226 additionally includes a wait control- 
ler 254 which generates a delay for compensating for 
CPU 228"s very high access speed. The wait controller 

45 254 is responsive to a timing signal (such as the bus 
cycle start signal (BCYST)) and clock and address sig- 
nals from CPU 228, and, after the appropriate delay in- 
terval, couples a ready control signal to CPU 228. 

Gate array 226 additionally includes an ID card in- 

50 terface 264, a printer interface 266, and a keyboard, 
pad, and mouse interface 268. The ID card includes an 
EPROM from which data is read. The ID card interface 
264 interfaces communications between CPU 228 and 
ID card 6. The printer interface 266 is an interface pro- 

55 vided for interfacing with a printer and includes in- 
put/output registers and other conventional printer inter- 
face circuitry. In the preferred exemplary embodiment, 
the printer interface 266 interfaces with a Centronics 
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printer. Keyboard, pad and mouse interface 268 controls 
the exchange of data and control signals between the 
keyboard 18, controllers ^2, ^4, mouse 16 and CPU 
228. Dialer 269 is coupled to CPU 228"s data bus and 
sends a dial pulse directly to modem board 22 shown in 
Figure 2B. Dialer 269 receives a digital signal indicative 
of a desired destination phone number and converts the 
digital signal to a pulse format for controlling modem 22. 

The gate array 226 additionally includes RGB inter- 
face 270 which, in the illustrative embodiment, includes 
a portion of the superimpose control circuitry of the su- 
perimpose controller 216, which is shown in Figure 28 
and is described in detail in Figure 23. The RGB analog 
output of signals accessed by main CPU 228 and PPU 
224 is superimposed on the analog output of signals 
processed by game CPU 200 and PPU 212. RGB 270 
includes circuitry for generating editing related image 
cell displays for controlling the modification of game play 
superimposed on game play related screens. The circuit 
receives superimpose related control signals (TOUMEI) 
from the CPU 228 and CPU 200. These control signals 
are output via a respective CPU 228 and 200 when an 
associated RGB signal is all zeros, i.e., transparent. 

The superimpose controller 216 is shown in further 
detail in Figure 23. In the exemplary embodiment, RGB 
270 includes the register GSEL 300, 4-1 MPX 302 and 
inverter 301 in Figure 23. Inverter 303 and analog 
switches 304 and 306 are not part of the gate array 226 
in one exemplary embodiment of the present invention 
but rather are disposed in the superimpose controller 
216 shown in Figure 2B. The GSEL register 300 as 
shown in Figure 23 is settable under program control by 
CPU 228. The GSEL register 300 bits MO, Ml are cou- 
pled as control inputs to multiplexer 302 to select which 
one of the four input signals to output from multiplexer 
302. The previously mentioned TOUMEI signals are in- 
put to multiplexer 302 by CPU 200 and CPU 228 when- 
ever there is a blank or empty space associated with the 
respective program execution. The TOUMEI signal from 
CPU 228 is coupled to multiplexer 302 via an inverting 
amplifier 301. 

Multiplexer 302 also receives "0" and "1 " input sig- 
nals. If, for example, the "0" input is selected by GSEL 
300 as the signal to be output, due to inverter 303, the 
analog switch 304 will be turned on (due to a "1 " at con- 
trol input) and the analog switch 306 will be turned off 
(due to the "0" at its control input). Thus, under these 
conditions, the RGB signal from CPU 228 will be cou- 
pled as the RGB output as opposed to the RGB output 
from game CPU 200. The reverse situation will occur if 
"1 " is the selected output of multiplexer 302. The visual 
effect from such a operation will be to switch back and 
forth from a game screen generated by a CPU 200 and 
a system screen generated by CPU 228. 

The selection of CPU 228 and CPU 200 TOUMEI 
signals controls priority of transparency if, for example, 
a system screen generated by CPU 228 should be dis- 
posed on top of a game screen generated by CPU 200. 



If a TOUMEI signal for game CPU 200 is output that in- 
dicates that the game CPU signal should be transparent 
and the main CPU 228 screen should overlay It. Thus, 
when the system screen is overlayed on the game 

5 screen or vice versa, either input D2 or D3 shown in Fig- 
ure 23 is selected. The 0 or 1 input determines whether 
a game screen or system screen is shown at all. For 
example, when the TOUMEI signal for CPU 228 is a "0" 
and is selected, due to inverter 301. the output of mul- 

10 tiplexer 302 will be a "1 " to result In the selection of the 
game CPU 200. When such a signal is output a game 
character can be seen through the clear dots of an icon 
associated with main CPU 228 execution. According to 
the setting of the GSEL register 300 by CPU 228, the 

^5 screen display and associated superposition of a game 
screen display and game editing display is controlled. 

Turning back to Figure 22, gate array 226 also in- 
cludes a game CPU interface 272. Game CPU interface 
272 includes the previously identified register copy RAM 

20 for receiving a wide range of game related information 
from CPU 200 via its address and data busses for mon- 
itoring by CPU 228. In addition, game CPU interface 272 
includes various buffers for supporting CPU 228 inter- 
communication in game debugging operations. The 

25 game CPU interface 272 also includes address and data 
trap related circuitry for performing conventional game 
debugging operations to permit the CPU 228 to debug 
game CPU 200 operation. Through game CPU interface 
272, CPU 228 becomes aware whether it is an appro- 
ve priate time period to initiate a system break operation. 

The gate array 226 also includes horizontal/vertical 
(H/V) timer and down counter 252 which is loadable by 
CPU 228 with a predetermined count for generating an 
interrupt control signal to interrupt controller 250. The 

35 H/V timer 252 uses the horizontal blanking (HBLANK) 
and the vertical blanking (VBLANK) timing signals gen- 
erated by PPU 212 as a timing base for counting. 
Through the use of the timing and counting circuitry 252, 
interrupts may be based on particular horizontal and 

■^0 vertical display positions for initiating certain operations 
such as, for example, a color change. The output of lim- 
ing circuitry 252 is coupled to interrupt request controller 
(IRQC) 250 which, in turn, controls the generation of in- 
terrupt requests which are coupled to predetermined 

^5 pins on CPU 228 as shown in Figure 22. 

As shown in Figure 22, gate array 26 also includes 
a communication interface RAM 256. RAM 256 includes 
the communication RAM handshake port, and buffer 
registers described above for receiving information from 

50 main CPU 228 and for coupling such information to 
game CPU 200 for loading in RAM cartridge 4. RAM 256 
is coupled to CPU 228 and CPU 200 address and data 
busses. An address decoder 258 receives CPU read, 
write and address signals from CPU 200 for controlling 

55 access to RAM 256 by CPU 200. 

Figure 24A is a simplified schematic diagram of 
RAM cartridge 4 which is used in the exemplary embod- 
iment of the present Invention to address potential prob- 
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lems which may develop under rare circumstances due 
to removal or insertion of a cartridge from the game 
processor system console 2 while the power is on. As 
shown in Figure 246= to preclude the unlikely possibility 
of cartridge components being damaged due to inser- 
tion or removal while the power is on, the pins in the 
cartridge edge connector are modified such that a pin 
which enables the cartridge RAM memory is shortened 
with respect to the power pin. 

Figure 24B shows the ground, address, data, reset, 
and power connectors for the cartridge 4. The reset pin 
from the game cartridge is shorter than the powerJine 
pin so that when the cartridge is pulled out even before 
the signal lines are disconnected, the enabling "reset" 
signal prevents the cartridge RAM from being written to 
prior to the power being disconnected. When the car- 
tridge is inserted, the power and data lines are connect- 
ed prior to the reset signal being placed in a high state 
to thereby enable writing to RAM 336 as a final opera- 
tion. In this fashion, the information stored in the car- 
tridge working RAM 336 is protected. When the car- 
tridge is inserted into its connector, power is applied pri- 
or to enabling of the cartridge memory circuitry. When 
the cartridge is removed, the cartridge circuitry is disa- 
bled before the power is disconnected due to the short- 
ened enable signal receiving pin. 

Turning to Figure 24A, when the cartridge is fully 
inserted with the power on, the reset signal (RES) is 
high. The reset signal is coupled to the enable input of 
a decoder 330 via a gating circuit 331 . Decoder 330 in- 
cludes one output coupled to a chip select pin of the 
game cartridge static RAM memory 336 (which is sche- 
matically shown in Figure 24A). A further decoder 330 
output is coupled to the chip select pin of four bit binary 
counter 332. The binary counter is initially set at 0. De- 
coder 330. which is coupled to the game cartridge ad- 
dress bus, detects a request to write to counter 332 and 
initiate the counter 332 to count up. When the writing 
pulse is given fifteen times, the counter 332 state is 1111 
and counter 332 generates an output signal which is 
coupled to gating circuit 334. If an attempt is made to 
write into SRAM 336 when the output of counter 332 is 
at a high level, a write signal is coupled to (each of the 
RAM modules which constitute) RAM 336 to thereby 
permit data to be written into the cartridge RAM. Thus, 
the cartridge includes a write protect circuit to require 
writing to a predetermined address area fifteen times 
before permitting writing data into the RAM to preclude 
any possibility of component damage or loss of data 
when the cartridge is inserted or removed with the power 
on. When an attempt is made to write to a predetermined 
address fifteen times, the cartridge memory system is 
in effect unlocked. In the game processing system of the 
illustrative embodiment, the time spent writing into the 
RAM cartridge 4 is very small. 

Figure 24A also shows a cartridge edge connector 
329. Among the signals coupled to the cartridge 4 are 
data signals and address signals carried on a data bus 



and address bus. Additionally, a reset signal is received, 
CPU read/write control signals and other control signal 
as received. The RAM cartridge shown in Figure 24A 
additionally includes a security chip 333 which operates 

5 with a security chip 227 in Figure 2A in a manner de- 
scribed in applicant's U.S. Patent No. 4,799,635 which 
patent is hereby incorporated by reference. As indicated 
above, further details of an illustrative security system 
employed in conjunction with the present invention are 

10 descnbed in the concurrently filed application entitled 
"SECURITY SYSTEMS AND METHODS FOR A VIDE- 
OGRAPHICS AND AUTHENTICATION GAME/PRO- 
GRAM FABRICATING DEVICE", Serial No. 08/332,812 
filed October 31,1 994. After RAM cartridge 4 is fully pro- 

is grammed for use in an SNES game system, the security 
chip 333 may be used as part of a security system to 
determine whether the cartridge is an authentic game 
cartridge in conjunction with the SNES game console 
that includes a corresponding security chip 333. Addi- 

20 tionally, CPU 228 receives the output from security chip 
227 and prevents game program execution and editing 
by CPU 200 unless there is a determination of authen- 
ticity in accordance with the teachings of "635 patent. In 
this regard both the security chip 333 and the-main CPU 

25 228 perform processing operations as generally dis- 
closed in U.S. Patent 4,799,635. Data indicative of the 
results of such processing are exchanged in a secure 
manner. If the main CPU 228 determines that the RAM 
cassette is not authentic based on data received via the 

30 gate array 226, the game CPU 200 is maintained In a 
reset state. 

Figure 24C is another illustrative way to implement 
cartridge circuitry corresponding to Figure 24A. Circuits 
in Figure 24C which correspond to like circuits in Figure 

35 24A are identically labeled and will not be further de- 
scribed. The one shot multivibrator generates the load 
signal to counter 332 when the CLK21M input carries 
no signal. The counter 332 is set to 0 by the load signal 
and writing into SRAM is disabled. In the normal oper- 

40 ation, the CLK21 M signal is continuously supplied from 
the console so the load signal is always disabled and 
the SRAM access can be accomplished in the same way 
as the circuitry of Figure 24C. 

Figure 24D shows an illustrative embodiment for 

45 cartridge connectors for use in conjunction with Figure 
24C. When the cartridge is pulled out, the CLK21 M and 
reset signals are cut off before the other indicated sig- 
nals are cut off. If the CLK21M input carries no signal, 
the load pulse is enabled. Thereafter counter 332 loads 

50 0 data and writing into the SRAM is disabled. In Figure 
24D, the address bus and data bus connectors are 
shorter than GND and VCC pins. Therefore, "LATCH 
UP" is prevented when the cartridge is pushed in while 
keeping power on. 

55 Figure 25 is a block diagram of reset related circuitry 
in accordance with an exemplary embodiment of the 
present invention. The system includes a reset button 1 
(347) and a reset button 2 (348), i.e., one reset button 
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associated with main system CPU 228 and one associ- 
ated with game CPU 200. Additionally, Figure 25 in- 
cludes a reset register 344 which enables main CPU 
228 to reset game CPU 200 via software control and 
reset logic 2 (342). As indicated in Figure 25, when the 5 
power supply 370 is turned on, reset logic 1 operates to 
reset main CPU 228 and clear reset register 344. Main 
CPU 228 may additionally be reset in response to de- 
pression of reset button 1 (347). Likewise game CPU 
200 may be reset by depression of reset button 2 (348). 
Alternatively, main CPU 228, by accessing an instruc- 
tion from its memory block 346, may set reset register 
344 to initiate the resetting of game CPU 200, i.e., to 
cause game CPU 200 to be held in a predetermined 
known initialization state such as the beginning of a ^5 
game program stored in memory 345. Figure 25 also 
generally shows an interface block 349 through which 
communications between CPU 228 and CPU 200 occur 
In another illustrative embodiment, the signal from reset 
button 348 may be given to the input port of CPU 228. 
CPU 228 couples the reset signal to SCPU 200 through 
reset register 344 when the reset button is pushed. 

Figure 26 is a block diagram of logic circuitry asso- 
ciated with initiating a system break to permit a user to 
modify the foreground or background of model game 
software. When a system break is to be generated, main 
CPU 228 generates a system break flag signal which is 
stored in flag flip-flop 350 through the latch. Bus status 
logic 360, which includes conventional comparator cir- 
cuitry and status indicating registers for identifying bus 
status, checks the game CPU 200 bus status to confirm 
that the CPU 200 is able to read out program com- 
mands. When bus status logic 360 determines that the 
CPU 200 is in a read/write cycle, the bus status logic 
360 generates a signal on output 361. When the CPU 35 
200 is in an instruction read cycle, bus status logic 360 
generates a signal on output 363 to indicate that it is 
ready to receive a command. 

As shown in Figure 26, an address decoder 362 is 
coupled to game CPU 200 system bus. Address decod- -^o 
er 362 detects the time when game CPU 200 accesses 
a predetermined program address area identifying a 
specific portion of the RAM cassette data (for example, 
the end of NMI routine). At such time, address decoder 
362 generates a signal on output 365 which is coupled -^5 
to an AND gate 366. AND gate 366 additionally receives 
an input signal from bus status logic output 361 . When 
both inputs of AND gate 366 are at a high level, the sys- 
tem break flag signal is set to flip-flop 350. Output 361 
is not high when game CPU 200 is reading instructions so 
from the RAM cassette 4 but rather is active when data 
is being read or written to RAM cassette 4. 

When the system break flag flip-flop 350 is set and 
when bus status logic output 363 is at a high level, indi- 
cating that the CPU status is "instruction-read-cycle", an ss 
enabling signal is coupled to system break logic 354. A 
system break is thereby initiated at a point in time when 
game. CPU 200 is about to read an instruction. At this 



point in time, CPU 200 is attempting to enable program 
memory 356 through generating an output enable signal 
via gating circuitry 358. System break logic 354 disables 
the coupling of output enable signal to program memory 
356 to interrupt the instruction read cycle and prevent 
the program memory output from being coupled to the 
CPU bus. 

The system break logic also outputs an instruction 
code referred to as a "COP" instruction. Then the COP 
command replaces an instruction to be read by CPU 200 
from program memory 356. The Monitor ROM copy pro- 
tect logic 368 outputs the enable signal to the gate 358 
after the COP command in reply to the signal from sys- 
tem break logic 354. Thus, the monitor ROM program 
in the program memory 356 can be accessed by CPU 
200 after the COP command is executed. When the 
COP command is received by CPU 200, the CPU exe- 
cutes its program instructions out of monitor ROM 204. 
Thus, the CPU 200 ceases executing the game program 
and begins execution of instructions out of monitor ROM 
204 in response to the COP command to thereby initiate 
control being switched to main CPU 228 for perform- 
ance of game editing and fabrication functions. 

Monitor ROM copy protect logic 368 additionally 
prevents unwanted read out of monitor ROM programs 
stored in program memory 356 when a game program 
is running. Therefore, the accessing from a user"s pro- 
gram purposefully made to copy the monitor ROM pro- 
gram is disabled. The circuit shown in Figure 26 through 
the use of the monitor ROM copy protect logic is useful 
as a monitor ROM program copy protect mechanism. 

DETAILED DESCRIPTION OF SYSTEM SOFTWARE 

Turning next to a more detailed description of sys- 
tem software, such software includes a game program 
editing tool referred to in the illustrative embodiment as 
"Mario Factory". Mario Factory is designed primarily for 
assisting unsophisticated users to easily create video 
games using mode! software. 

Figure 27 is a flowchart which shows the sequence 
of operations in accordance with an exemplary embod- 
iment of the present invention from power on through 
the appearance of the "Mario Factory" utility title screen. 
After the power is turned on (385), an initial sign-on 
screea is displayed (386). Thereafter a copyhght infor- 
mation display is generated (387). A check is then made 
to determine whether the game editing tools associated 
with the illustrative embodiment are already stored in 
flash memory 236 shown in Figure 2B (391 ). If the check 
at block 391 indicates that the tools are in flash memory 
236, then the tools are transferred to DRAM 230 asso- 
ciated with CPU 228 and the Mario Factory execution 
may begin. Thus, if the editing tools are already in the 
flash memory, Mario Factory is automatically loaded. If 
the check at block 391 indicates that the editing tools 
are not in flash memory 236, then a check is made at 
388 to determine if the tool diskette is in the floppy disk 
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drive. If the floppy disk diskette is not in floppy disk drive 
199, then a nnessage is displayed to the user indicating 
"please insert the tool disk" (389). Upon detection of the 
tool disk being inserted^ a tool installation screen is gen- 
erated (390) and the Mario Factory loading is complet- 
ed. 

In accordance with one exemplary embodiment of 
the present invention, the model software is loaded such 
that two distinct files are stored: a base file containing 
non-modifiable aspects ot the game and a user file con- 
taining those elements of the game that a user may 
modify. Alternatively, only the base file need be initially 
loaded to provide the user with the fundamental aspects 
of game play from which to build upon and create new 
games within the genre of games associated with the 
base file. 

The check at block 392 determines whether the 
model software is in the floppy disk drive. If the model 
software is not in the floppy disk drive 1 99, the user will 
be prompted to install the model software disk (394) and 
a model software load screen is generated (393). There- 
after a check is made if a user file has been selected by 
the user (395). The user file may be loaded on a different 
disk than the base file (which is why the selection of the 
user file in block 395 may require the insertion of another 
disk). The user file contains the changes made to the 
model software video game to date. Initially the user file 
is in a default stage where the model software defines 
the initial game play. As the user changes the game, the 
default information is changed to reflect the user's edi- 
torial modifications. Both the game cartridge and the 
floppy disk include a base file and user file, however, the 
floppy disk will store the original default version of the 
game whereas the game cassette will not. The RAM 
cassette data is modified in real time such that default 
data is not resident on the cassette 4. Once the user file 
has been selected, a user file load screen is displayed 
(398). If a user file is not selected, the user will be 
prompted to insert a user disk (396) and the user will 
have an another opportunity to select a user file (397). 
Thereafter a utility title screen (399) is displayed such 
as shown in Figure 5. 

In block 392 the model software may be changed 
as desired by the user by inserting another disk. Once 
the utility title screen is displayed, a user may click a 
particular file icon which leads to branching back to 
block 395 in which the user can select another user file. 
Alternatively, the routine may branch back to block 392 
in which the entire genre of games may changed by 
changing the modei software. The Mario Factory pro- 
gram Includes a large variety of editing tools such as 
"dot" for drawing particular characters "animation data" 
for controlling animation, etc. 

The game processor system, in accordance with 
the exemplary embodiment described herein, includes 
software under the control of CPU 200 and software un- 
der the control of main CPU 228. The software operated 
by the CPU 200 includes the model game software de- 



scribed above and user fabricated game programs. The 
main CPU 228 executes various utility programs, oper- 
ating system, peripheral driver programs, and BIOS and 
IPL software. The utility software operated by the main 

5 CPU 228 includes game editing tools, network software, 
word processing software, disk management software, 
etc. The operating system and peripheral driver soft- 
ware includes subroutines for supporting peripheral de- 
vices not fully supported by the BIOS software de- 

^0 scribed below. 

The BIOS software includes iow level routines for 
direct interaction with the above described system hard- 
ware. More specifically, the exchange of information be- 
tween the main CPU 228 portion of the system and the 

^5 game CPU 200 subsystem is controlled from a software 
perspective by way of two BIOS operating system rou- 
tines, one of which is resident in BIOS ROM 234 and 
the other which is resident in monitor ROM 204. The op- 
erations performed during such information transfer by 

20 these operating system routines are described below. 
The BIOS routines control the various I/O devices 
shown in Figure 2A and 2B such as mouse 1 6, keyboard 
18, controllers 12 and 14, display 15, modem 22, and 
control processor intercommunication, memory mainte- 

25 nance functions and PPU control functions. PPU-212 
functions controlled by the CPU 200 BIOS software in- 
cludes, for example, setting of the PPU"s color gener- 
ating RAM to define predetermined desired color maps, 
transferring data to the VRAM 21 4, setting superposition 

30 priorities, etc. Screen display related functions that are 
controlled include setting the cursor position. Keyboard 
functions that are controlled include keyboard initializa- 
tion, obtaining keyboard buffer data and obtaining key- 
board status information. Similarly, for the mouse, a va- 

35 riety of functions controlled by BIOS software including 
mouse initialization, obtaining the cursor position of the 
mouse, etc. BIOS software associated with controlling 
operations of the game CPU 200 include initialization of 
the game CPU, transferring data to the sound processor 

^0 208, working RAM 210, and functions associated with 
the exchange of data with the main CPU 228. The BIOS 
software associated with the main CPU 228 includes 
controls functions such as setting the real time clock, 
checking the time-out counter in gate array 226, and 

•^5 performing operating system housekeeping functions 
such as those which are typically performed in conven- 
tional operating systems such as MS DOS. The operat- 
ing system software is capable of receiving some com- 
mands from other computers so that game programs re- 

50 ceived via the SCSI board 24 in Figure 2B from an IBM 
compatible PC may be executed and edited. 

The IPL software is responsible for initial program 
loading such that when the system is booted up it checks 
the game processor system status and boots up the 

55 BIOS in the operating system routines. The initial pro- 
gram loading (IPL) routine is executed upon system 
start-up and initially results in the display of the start-up 
message, including a copyright notice as referenced 
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above in conjunction with Figure 27. Thereafter the IPL 
performs an ID code check in which a cyclic redundancy 
code (CRC) in the membership ID card is checked. If a 
determination is made that the ID card is authorized, the 
system is booted up. If the ID check reveals that the ID 
is unauthorized, a display is generated indicating a lack 
of authorization. If the ID code check passes to permit 
the system to be booted up, a hardware status check is 
made. The hardware status check determines the size 
of the RAM of the current system configuration and 
checks to make sure the connected RAM is readable 
and writable. Thereafter checks are made to confirm 
that the floppy disk driver, modem, printer hard disk and 
other devices within the control unit and expansion unit 
are appropriately connected. If all hardware status 
checks do not confirm proper connection, an appropri- 
ate display is generated to indicate a system fault. 

If all hardware status checks indicate proper con- 
nection, then a check is made of the operating system 
ID code. In this check an ID code within the operating 
system is checked and boot up proceeds if the check 
passes. If check fails, then a display indicating a system 
fault is generated. If the ID code check confirms the 
proper ID code then the operating system is booted up. 

The security checks are designed such that at mul- 
tiple levels throughout the system, there are security 
systems implemented. As noted above, in the initial pro- 
gram loader (IPL), an ID code check is made to detect 
an unauthorized ID card. An ID code check is also made 
to indicate the use of an unauthorized OS/BIOS. Addi- 
tionally, as described above, a security chip is utilized 
in the RAM cassette 4 determines whether the system 
is connected to unauthorized hardware. Additionally, at 
the BIOS/OS level, an ID code check is made to deter- 
mine whether there is inappropriate access to a base 
file. An ID code check also determines whether there is 
unauthorized network access as well as use of unau- 
thorized utilities. If these ID code checks fail, the at- 
tempted file operation is disabled. The BIOS/OS also 
uses an associated, unique data formatting and/or file 
compression methodology that makes read-out by ma- 
chine architectures, other than that described herein, 
difficult. 

The operating system includes a kernel portion 
which interprets commands, manages memory, reads 
in transient operating system portions and starts up 
command routines. The kernel reads in a file called 
"configuration file" from the ID card, which records such 
things as the set up of peripheral drivers and unpacks 
the transient operating system, transient BIOS, periph- 
eral drivers, etc. on to memory and manages them. A 
command routine portion of the operating system in- 
cludes subroutines that perform actual operations 
based on instructions from the kernel and the peripheral 
driver section of the operating system includes subrou- 
tines that handle access to the various peripherals as 
described above. 

Files are typically organized containing a 64-byte 



header file which includes such fields such as file name, 
date, file size, file attribute, code maker, ID code, pass- 
word, etc. The file author is recorded only in the base 
file and the purchaser"s ID code is recorded at the time 

5 of purchase. The file attribute field includes bits which 
enable a file only if an ID code matches an author code 
or alternatively, enables a file only if there is a password 
match. Depending upon the state of the file attribute field 
or other bits, it is therefore possible to enable a file, dis- 

^0 able a file or enable based on whether certain security 
checks are passed. The file attribute information may 
set various conditions for base file access such as if ac- 
cess is made by the purchaser, writing is disabled, if not 
made by the purchaser reading and writing are disabled 

^5 and the file name is not displayed. The operating system 
includes basic file access commands (such as load, 
save, verify, copy, etc.), file management commands, 
network commands, password commands and RAM 
cartridge commands. The system uses a password 

20 command which sets a password as a configuration var- 
iable. It is compared against the password in the header 
file. If the configuration variable has not been set, it is 
considered as having no password. 

As set forth above, model game software is soft- 

25 ware which assists in game fabricating and which is ex- 
ecuted by the game CPU 200. It is designed so that orig- 
inal games can be created through simple game author- 
ing tool operations. In a preferred embodiment of the 
present invention, model software will be distributed ac- 

30 cording to various game genres such as "shoot-em- 
games", role playing games, etc. The description herein 
sets forth the details of an exemplary game authoring 
tool referred to herein as "Mario Factory" which is de- 
signed primarily for game fabrication by those uninitiat- 

35 ed with video game program design and authoring. The 
present invention, however contemplates the use of 
game authoring tools for intermediate and more ad- 
vanced users which will be permit even more sophisti- 
cated creations than those described herein. fHowever, 

^0 the presently preferred embodiment is described in the 
Mario Factory. The model software includes a base file 
and a user file. The base file is a file which a user cannot 
change and includes a portion of the model software and 
its associated original game which is not changeable by 

^5 the user The user file is a file which may be changed 
by the user The user file includes default programs and 
default data which a user may modify to create user orig- 
inal programs and user original data. The base file is 
copy protected so that the only way to obtain a copy of 

50 the base file is to purchase the model software. The user 
file is not copy protected and can be obtained freely by 
uploading it on a network, for example. Original games 
created by a user may be transmitted to other users by 
a transmission of the user file. 

55 In Mario Factory, games are processed by process- 
ing many constituent "units". For example, in Figure 28, 
a Super Mario screen is shown with a unit 1 being iden- 
tified as Mario, which is a player controlled unit (e.g.. 
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controlled by a game controller 12, 14), a unit 2, which 
is labelled an "enemy" unit and a unit 3 which is a music 
unit. Significantly, all data and algorithms relating to a 
unit, such as graphic data, the appropriate responses to 
keys, and sound effects are stored for the unit, as is de- 
scribed below. This system also provides for music units 
which are not associated with graphic data. The game 
is edited by selecting a tool icon to make changes. For 
example, for Figure 28, if the unit 1 is selected, a tool 
selection may be made in which the Mario graphics 
sound or programmed responses to conditions. From a 
programmer"s point of view, a unit may be considered 
as a memory space for storing game play characteristics 
and a wide range of other data allocated on the game 
CPU 200 side. 

As previously described, the preferred embodiment 
of the present invention includes a wide variety of editing 
tools for changing pictures, sounds and programs. Edi- 
tors that are specialized for certain games may be in- 
cluded in the model software as expansion software. For 
example, for a shooting game specialized map editors 
or enemy path editors may be utilized. Similarly, for a 
role playing game, specialized map editors, dialogue 
editors and event editors may be included and in a puz- 
zle game, a rule editor may be included as expansion 
software. 

Each of these various types of tools are displayed 
for selection by the user. Icons are organized in layers 
and only the icon that is needed at a particular moment 
is displayed to the user Unnecessary icons are not dis- 
played, rather, they are recorded in the status file includ- 
ed in the model software. 

Game editing revolves around the editing units and 
associated data structures. In an embodiment of the 
present invention, different editing functions are control- 
led based upon icon clicking at system break or from the 
tool box screen. In another illustrative embodiment, they 
are controlled based upon whether the left or right 
mouse button is depressed. After game play has begun, 
a system break is initiated and a mouse cursor appears 
on the screen. If it is desired to edit a particular unit dis- 
played on the screen, for example, the left mouse button 
is clicked over one of the units shown, for example, in 
Figure 28 and all the tools for editing the selected unit 
are displayed including graphics editing, program edit- 
ing and sound editing features. If the right mouse button 
is clicked, various options are displayed such as "undo", 
"game", "file", "tool list", "unit" and "end". If the tool list 
option is selected, tools may, for example, be shown as 
a tree chart and the units that can be edited with the 
selected tools may be controlled to blink. 

During this process, the edit screen is superim- 
posed upon the game screen. After the desired edits 
have been made, game piay may be resumed. In left 
mouse button edit operations, after a game screen is 
displayed and a system break is initiated, the mouse 
cursor appears on the screen and the user clicks on a 
character to be edited. The character to be edited ap- 



pears in a box with the unit identified. Thereafter, mod- 
ification of the unit takes place via the various editing 
tools. After editing, game play may be resumed. 

With respect to right mouse button edit operations, 

5 on a combined screen a tool list is generated. The user 
then selects a tool and each of the editable units will be 
displayed for that tool. Thereafter via the mouse, anoth- 
er tool may be selected and different editable "units" will 
be displayed. If a character is clicked on, the character 

10 appears in a box and a menu appears and editing con- 
tinues in an identical manner as with left mouse button 
editing. In right mouse button editing, during fVlario Fac- 
tory operation, the status file is checked and the status 
is displayed. The unit header (which is a data area 

IS placed at the head of the unit storing information such 
as the tools with which the unit can be edited) is then 
checked and editable units are found. 

In the present system, due to the model software 
selection screen, even without the model game software 

20 itself, the Mario Factory authoring tool can be started up 
and basic tools can be used. The Mario Factory program 
includes a status file, which is a text file which records 
the label names of tools to be placed in memory. By ac- 
cessing the status file, the Mario Factory program can 

25 determine which tools need to be stored in DRAM 230. 
Some of the toots stored in DRAM 230 are displayed as 
icons. Such tools may include basic tools and expansion 
tools chosen from an object file written in main CPU 228 
code. 

30 Figure 29 is a block diagram which functionally 
demonstrates how programming is structured on a "unit" 
basis. Within the memory address space 401 of game 
CPU 200 is stored unit related data uniquely identifying 
each of the units which may be edited. There is a one- 

35 to-one correspondence between units which may be ed- 
ited and unit related data structures stored in the game 
CPU memory address space. 

As shown in Figure 29, if a user selects unit 3 shown 
on display screen 15 during, for example, a system 

40 break operation, a corresponding portion of memory 
space 401 will include a unit data structure (or pointer) 
associated with unit 3 which will store (or point to) a unit 
header, a data table and a unit 3 related program. The 
unit header includes labels for tools that can be used to 

-^5 edit the particular unit and the storage address for edited 
data. The group of unit headers are also stored in the 
main CPU 228 address space. The data table includes 
data relating to a wide range of game play/object char- 
acteristic information to be described below including 

50 not only graphics and sound but also information indic- 
ative of the path movement for each character In es- 
sence, the graphics, sound and program associated 
with each unit may be viewed as being carried with or 
pasted on each unit. 

55 The main game processing routine includes a se- 
quence of instructions for processing each of the units 
1 to N. The main routine (405) includes a sequence of 
jump to subroutine (JSR) for accessing the respective 
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unit programs. Each unit program includes instructions 
designed with the assumption that it may be called up 
from the main routine during any given frame. The main 
routine 405 also includes a jump to the main CPU com- 
munication routine. This communication routine han- 
dles such operations as signal transmission of a mouse 
click point to the main CPU, and reception of signals re- 
lating to editing data associated with the editing tools 
and checking for a mam CPU system break signal. 

Figures 30A through 30C are a flowchart delineat- 
ing the sequence of operations involved in processing 
unit data and outputting picture and sound signals to a 
user"s display screen. As indicated in Figure 30A, unit 
processing begins with the system referencing a unit 
map screen, which indicates the disposition of units by 
the unit screen editor. For example, if the background 
screen is scrolled by key control a new portion on the 
unit screen map is referenced to judge whether new 
units appear (405). After a unit initialization process 
(406) in which the new unit is found on the unit map 
screen, an entry is made in the active unit list, the unit 
access counter is set to unit 0 (407) and the routine en- 
ters a unit processing loop in which the unit offset ad- 
dress is calculated (408). As indicated in block 409, the 
unit program associated with the unit is executed, and 
when applicable, animation processing (410) and sound 
processing (41 1 ) are performed. The counter is then in- 
cremented which keeps track of the unit to be accessed 
(41 2) and a check is made to determine whether the last 
unit number has been accessed (413). If the check at 
block 41 3 reveals that the last unit number has not been 
accessed, then the routine branches back to block 408 
in which the next unit number to be processed is located 
in memory via the offset address calculation. 

Figures 30B and 30C show the animation process- 
ing of block 41 0 in further detail. As shown in Figure 30B, 
animation processing begins by identifying a pose 
number to be displayed for the unit being processed 
(414). Thereafter the character address is calculated 
(424) and the character data stored at the calculated ad- 
dress is transferred to a memory buffer area for process- 
ing (425). A check is then made at block 426 to deter- 
mine whether a user data override flag has been set. If 
the user override flag has been set, then the user se- 
lected data is overridden (427). If not, then the character 
data stored in the buffer area identified at block 425 is 
transferred to the object attribute memory area (428). 

Figure 30C shows the processing steps involved in 
deciding the display pose number for processing in Fig- 
ure 30B"s block 414. Initially, a check is made at block 
415 comparing the display ANIME number with prede- 
termined backup data stored with the "unit" as shown in 
Figure 33. If there is a match, then the routine branches 
to block 417. If there is not a match, then the ANIM E 
data is transferred to the object unit RAM shown in detail 
in Figure 33. Thereafter, "tempo" data is subtracted from 
the contents of the frame counter (41 7). A check is then 
made to determine whether the frame counter is less 



than zero (418). If the frame counter is less than zero, 
then the pose number is incremented (419). A check is 
made to determine whether the pose number is over the 
maximum allowable pose number (420). If the pose 

5 number is over the maximum, then the pose number 
(421), which determines unit pose in the animation se- 
quence, is set equal to POSE MAX after # defined using 
the animation tools such as in Figure 10. Thereafter, the 
pose data is transferred to the buffer area identified with 

10 respect to Figure 308, block 425, and the pose point 
location data (x,y) is transferred to the buffer (423). If 
the frame counter is not less than zero, then the routine 
branches directly to block 423. 

Figure 30D is a flowchart of the sound processing 

?5 associated with the unit being processed. Initially, a 
check is made at block 429 to compare the status reg- 
ister and the status register backup as stored in the ob- 
ject unit RAM shown in Figure 33. If the check at 429 
reveals that there is not a match, then a calculation is 

20 made to determine the sound effect data offset address 
430. The sound effect number is calculated based upon 
the unit entry address added to the calculated sound ef- 
fect offset address (431). The sound effect number is 
thereafter sent to the sound processor 208 port (432). 

25 Real sound effect data is stored in WRAM 21 0 with eve- 
ry sound effect number. The sound processor makes 
sound with the sound effect number and real sound ef- 
fect data. If the check at block 429 indicates that the 
status register contents equal the status register backup 

30 contents, then the sound processing subroutine is exit- 
ed and the routine continues processing at Figure 30A 
block 412. 

Figures 31 and 32 depict illustrative first and second 
model software formats structured such that main CPU 

35 228 is able to efficiently process the information to per- 
mit ease of editing. Much of the information in Figures 
31 and 32 will not be described here but will be under- 
stood by those skilled in the art in light of the description 
herein. As shown in Figure 31, the first model software 

■^0 format is background related and contains a "stage" 
pointer section which points to stage (background) data 
stored at an identified set of locations in memory. The 
stage data in turn points to a wide variety of additional 
information such as font data, color palette data and oth- 

^5 er background related data such as the MAP DATA, 
UNIT MAP DATA, PANEL MAP DATA. PANEL UNIT 
MAP DATA and PANEL DATA. 

Figure 32 illustrates a second moving object related 
model software format in which identified "object units" 

50 such as Mario are assigned an associated object unit 
memory partition. Associated with each identified object 
unit is an object animate (ANIME) pointer which points 
to the block of animation data as shown at Figure 32. 
Additionally, each object related unit includes object pro- 

55 gram pointer information identifying the various pro- 
grams associated with each object unit. 

Figure 33 depicts an illustrative memory map of 
RAM information contents including an object unit RAM 



20 



BNSDOCID:<EP 0713174A1 I > 



39 



EP 0 713 174 A1 40 



information area and a game background related RAM 
area. As shown in Figure 33, the object unit infornnation 
includes the object unit ID, status register and coordi- 
nate location and a wide range of other object infornna- 
tion such as character size, pose information, etc. This 5 
information is stored in the buffer area of main CPU 228 
and DRAM 230. which is shown in Figure 2A and is used 
to edit with the control file. The control file has some 
cross reference data, label text and message text for 
assisting in editing. The data stored in the control file is 
not needed for game program execution but, is used to 
make editing easier. The background music data that is 
utilized during game play is transferred from main CPU 
228 system portion back to game CPU 200 section. 

Figure 34 depicts main CPU 228 and game CPU is 
200 memory maps and identifies the manner in which 
data is extracted and copied from game CPU 200 to 
main CPU 228 during a system break. It also depicts 
how certain common values are maintained in each 
memory area during editing so that main CPU 228 and 20 
game CPU 200 can efficiently coact. 

In the data area in the CPU 200 portion of Figure 
34, graphic data, sound data and status (process pro- 
gram) are stored as animation data, ASM data and BA- 
SIC data. The memory area of game CPU 200 also in- 25 
eludes the main program described in conjunction with 
Figure 29 and the associated the main processor com- 
munication routine in SHVC-BIOS. The uneditable base 
file that is provided with copy protect mechanisms is 
stored as a portion of the data area, unit pointer and the 30 
assembler main program. In the main CPU 228 memory 
system, in addition to the basic editing tools of the Mario 
Factory, the CPU code is stored. The memory area of 
CPU 228 also includes the main program area to store 
the operating system program and main CPU commu- 35 
nication routine. Additionally, the base file is stored as 
the control file and some portions in buffer areas includ- 
ing unit data, unit pointer and certain minor data for ed- 
iting. These elements are loaded via the load program 
controlled by the user's model software selection in the 40 
Mario Factory program. 

When the Mario Factory is executed, the execution 
results in the allocation in the main CPU 228 memory 
as shown in Figure 34 and the display of the title screen. 
Then, if the load icon is clicked, certain files of the model ^5 
software are loaded in CPU 228 memory and certain 
files are loaded to the game CPU memory via the com- 
munication routines in each memory. The model soft- 
ware includes some unit information written to the data 
area and unit pointer in SCPU 200 memory. The model 50 
software also includes the control file data that is the 
minor data for editing as cross reference data, label text 
or message text which is stored in the control file area 
in CPU 228. The control file data includes the attribute 
data to indicate whether the edited data is base file data 55 
(disable the edit) or user file data (enable the edit). In 
addition, the control file data includes the limit data to 
indicate the limit of editing. For example, a limit may be 



set specifying that Mario speed cannot be above one 
frame/8 dots. In accordance with an illustrative embod- 
iment of the present invention, the user file includes the 
data area data and unit pointer data except for unit in- 
formation of the base file. The user data also may. in- 
clude the differences between the default data and ed- 
ited data. 

The flowchart of Figure 35 delineates the sequence 
of operations performed by the game CPU 200 and the 
main CPU 228 during game fabrication processing. It 
illustrates how a game program is executed, stopped for 
making game modifications and then resumed from the 
point at which editing occurred. 

The left portion of the flowchart depicts the flow for 
game CPU 200, whereas the right side of the flowchart 
indicates the flow for main CPU 228. 

The flow of main CPU 228 is shown in parallel with 
the game CPU flow to demonstrate the interaction and 
data exchange. Such interchange results from the stop- 
ping of a game screen and the selection of a particular 
unit for editing, e. g, Mario. The arrows between the col- 
umns indicate an exchange of data between the two 
processors. 

Initially, once game play is to commence, the game 
CPU 200 is in control and begins executing the main 
routine for playing a game embodied in the model soft- 
ware as previously described (433). When a system 
break is initiated, a COP command is generated, as pre- 
viously described, to cause a vector jump resulting in 
the software being executed out of the monitor ROM 
204. When a system break is imposed and, for example, 
the character Mario is selected for modification, a unit 
identifier is generated. Information which is being 
changed during the system break is stored in the CPU 
work RAM 202. After the vector jump, game CPU exe- 
cutes out of the monitor ROM 204. 

As shown in Figure 35, the main CPU 228 executes 
a program loop to be described below, awaiting a stop 
request from the user for making a change in the model 
software game play. When the mouse button is de- 
pressed by the user, a stop request is detected (440) 
and a software interrupt occurs in which a COP com- 
mand is coupled to the game CPU (441 ). 

If the system break is imposed while the screen dis- 
play is being created, the generated display wilt be com- 
promised. The SCPU BREAK LOGIC shown in Figure 
26 delays the system break until no impact is possible 
on the generated displays such as at the end of a non- 
maskable interrupt (NMI) which occurs, for example, 
during the vertical blanking interval. When main CPU 
228 provides a COP command to CPU 200 via the 
SCPU BREAK LOGIC at the end of the NMI interval, 
CPU 200 begins executing out of monitor ROM 204 to 
transfer data to be changed to main CPU 228 buffer ar- 
ea. The main CPU 228 is informed of the coordinate po- 
sition of the character to be changed, the size of the ob- 
ject and the identifying unit number. The unit work RAM 
area of CPU 228 includes status information relating to 
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the object. Thereafter, the game CPU responds by be- 
ginning to execute out of monitor ROM 204. 

As indicated at block 434, ganne CPU 200 sends 
the unit work selected to nnain CPU 228 which receives 
the unit work (442). As can be seen in the nnemory nnap 
shown in Figure 34 the unit work is contained in the CPU 
200 mennory space and a copy of the identified unit work 
is transferred to the nnain CPU 228 unit work copy area. 
Figure 33 shows illustrative stored information relating 
to an object unit and Figure 36 show a unit pointer area 
for active units and representative unit information for 
an identified active unit such as unit ID number display 
points, character size, program counter in the unit, etc. 
Figure 37 shows a unit pointer area for all units which 
identifies exemplary unit pointer data such as animation 
data pointer program pointer sound pointers, etc. !n the 
preferred embodiment, all the unit information shown in 
the right hand column of Figure 33 would be placed in 
a work copy area. 

Turning back to Figure 35, after CPU 200 sends out 
the unit work and after reception by main CPU 228, a 
search is made based on the cursor position to deter- 
mine where the unit is located (443). The unit work re- 
lates to all the units displayed on a particular frame. Out 
of those active units, the user chooses a target unit to 
operate on. The object attribute information relating to 
the objects which may be processed are written into the 
object attribute memory associated with CPU 228 and 
the memory is monitored so that it can be determined 
where the modified units are to be displayed. Thereafter 
a dialog box is displayed identifying a unit to be modified 
as has been previously described (444) and a superim- 
pose request is turned on to thereby result in a display 
of both the game screen and a dialog box. The user may 
then choose a particular target unit to modify (445). After 
the user chooses a target unit, a further dialog box ap- 
pears in which the user chooses an object mode (446). 
For example, the object mode to be selected may be the 
"dot icon" in which the user may change the character 
configuration on a dot by dot basis. 

Game CPU 200 waits for the data request in a loop 
(435) and ultimately receives a request from main CPU 
228 (447). Current user data is sent by CPU 200 as in- 
dicated in step 436 and main CPU 228 takes this data 
(448) and with one of the editors described herein, 
changes the data (449). 

On the game CPU 200 side, the game CPU waits 
for a new data unit (437) which is being edited by main 
CPU 228 and receives the new data unit at block (438) 
which is sent to game CPU 200 via step (451) of main 
CPU 228 routine. The game CPU 200 also receives a 
data pointer at block 438 which is a two byte data block 
identifying the change made to the unit. After the infor- 
mation is received in block 438, game CPU 200 goes 
into a restarting process to resume execution of the 
game with pointers changed to identify the new unit in- 
formation. 

Through return from interrupt instructions, the game 



program continues at the same point in which the sys- 
tem break occurred. The return from interrupt is initiated 
after the COP instruction is no longer issued which oc- 
curs after the desired change has been made. The main 

5 CPU 228 branches back to block 440 where it stays in 
a loop awaiting another stop request. 

Figures 38A and 38B is a flowchart showing how 
game program processing takes place using "unit work" 
table processing techniques in accordance with the 

^0 present exemplary embodiment. When the main routine 
game program (450) begins executing, the game CPU 
200 is initialized (452) and initial values are loaded into 
the unit work area. Thereafter default data is set in the 
unit work area in accordance with the original data in the 

15 model software (454). Based on such initial data, an in- 
itial display is generated (456). Thereafter the entire 
main routine is processed during a main table process- 
ing subroutine 458 and blanking and VRAM refresh 
processing (460). 

20 Figure 388 is a flowchart showing the main table 
processing (458). The MAIN TABLE corresponding to 
the stage status in Figure 31 indicates the game se- 
quence. It is the upper most program routine of the pro- 
gram layers and the mode! software flow shown in Fig- 

2S ure 30A is executed by the MAIN TABLE. When the pro- 
gram process 409 in Figure 30A is executed, the UNIT 
ACTION TABLES corresponding to the OBJ status in 
Figure 32 is referenced for each unit. In the main table 
processing subroutine 458, initially a reference is made 

30 to a condition identified in the main table such as the 
exemplary main table shown in Figure 39 (462). As 
shown in Figure 39, the main table includes a "condition" 
column and a "process" column. The condition column 
includes a number of routine addresses pointing to sub- 

35 routines relating to identified conditions. Turning back 
to Figure 38B, a check is made at block 464 to determine 
whether a predetermined condition identified in the con- 
dition column is met. The condition check is determined 
by the state of the "BINGO" Flag. If the predetermined 

40 condition is met, then the main table is referenced to 
identify the processing which takes place corresponding 
to the condition. The processing operation indicated in 
the processing column is performed by executing the 
process that is pointed to by the routine address pointer 

45 associated with the process identified in the process col- 
umn. If the condition is not met as determined by the 
check at block 464, the main table processing routine 
branches to block 468, where a check is made to deter- 
mine whether the main table has ended. If not, the rou- 

50 tine branches to the next condition of the main table and 
continues such processing until all the entries in the 
main table have been processed whereupon a return to 
the main game program routine shown in Figure 38A 
occurs (470). , 

55 Focusing back on the main table of Figure 39, the 
entry relating to the "must" condition points to an ad- 
dress of a "must" routine which specifies a condition in 
which the unit must behave in a certain manner In ac- 
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cordance with the must subroutine shown in Figure 40 
(475); a flag called "BINGO" is set to 1 (477) which 
means that the condition always will occur and the rou- 
tine returns to the main table processing routine (479). 

Figure 41 shows the "Enemies Wipe-Out" condition 
subroutine (480) shown in the main table. This routine 
determines whether the enemies are eliminated and 
sets the "BINGO" flag. Figure 41 also represents the "All 
Friends Wipe-Out" condition subroutine to determine 
whether all friends are destroyed (480). In accordance 
with the enemy (or friend) wipe-out routine, a check is 
initially made to determine whether the number of ene- 
mies (or friends) is equal to 0 (482). If the number of 
enemies (or friends) equals 0. then the BINGO flag is 
set to 1 (484) and the routine branches back to the main 
table processing subroutine. The Go Next Stage sub- 
routine in Figure 44 (or Go Ending subroutine in Figure 
45) is then executed in process 466 in Figure 38B. If the 
number of enemies (or friends) are not equal to 0 then 
the BINGO flag is set to 0 (486). Thereafter the routine 
returns to the main table processing routine. The corre- 
sponding process is not executed. 

In accordance with the "unit action" subroutine 
process in the main table (500)= a unit action table is 
processed such as the illustrative unit action table 
shown in Figure 42 which, for example, describes ac- 
tions relating to a "turtle" unit work. Focusing on the con- 
ditions specified in the unit action table, each of the con- 
ditions as well as the processes are identified by ad- 
dress pointers to a subroutine responsible for the con- 
dition and processing. The "must" condition routine has 
previously been explained in conjunction with Figure 40. 
The condition following "must" relates to when the turtle 
is detected touching the right edge of the screen. The 
"BE-TREADED" condition refers to when the turtle is 
stepped on by another object. When the condition on 
the left side is met, the process indicated by the asso- 
ciated address pointer is executed. The processes as- 
sociated with each of the conditions in the table shown 
in Figure 42 are self-explanatory. 

In accordance with the "unit action" subroutine 
shown in Figure 43 (500), initially the routine references 
the unit data in the unit work area in Figure 34 (502). 
Thereafter, the contents of the unit action table shown 
in Figure 42 are processed by accessing the subroutine 
indicated by the routine address associated with each 
of the conditions (504). The unit action table may be 
modified by the user through the status editor using the 
display screen shown in Figure 1 7. A check is thereafter 
made to determine whether a condition has been met 
(506). If the check at block 506 indicates that the condi- 
tion has been met, then the process portion of the table 
in Figure 42 is accessed to perform the associated 
processing such as, for example, move the turtle to the 
right (508). It the first condition associated with the unit 
action table is not met then the routine branches to block 
510 where a check is made to determine whether the 
table is at an end by detecting the end mark. If the table 
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has not ended, then the routine branches back to block 
504 and processing continues. If the table is at an end, 
then a check is made at 51 2 to determine whether there 
are no more units to be processed. If this check does 

5 not reveal that there are no more units to be processed, 
the routine branches back to block 502. If there are no 
more units to be processed, then the routine returns 
back to the calling routine (514). 

Turning back to the main table (in Figure 39), if the 

10 condition Enemies Wipe-Out is detected, then the "Go 
Next Stage" routine is executed which is shown in Figure 
44 (516). Initially, the stage number is incremented to 
initialize for the next stage (518). Thereafter the unit 
work area in Figure 34 is cleared (520), some units are 

IS set and the background picture is displayed for the next 
stage (522). The next main routine is set to the next 
stage routine. Thereafter the routine branches back to 
the calling routine (526). The last process shown in the 
main table is the "Go Ending" process which is executed 

20 upon detection of a friend"s wipe-out condition. As 
shown in Figure 45, when the Go Ending subroutine has 
been called (528) the unit work is cleared (530). There- 
after units are set for ending (532) and the associated 
picture is displayed (534). The routine then .^branches 

25 back to the calling routine (536). The next main routine 
is set to the ending stage routine. 

While the invention has been described .in connec- 
tion with what is presently considered to be the most 
practical and preferred embodiment, it is to be under- 

00 stood that the invention is not limited to the disclosed 
embodiment, but on the contrary, is intended to cover 
various modifications and arrangement included within 
the spirit and scope of the appended claims. 

35 

Claims 

1. An interactive computing system for editing a vide- 
ographics program comprising: 

40 

a first processor that is operable to execute a 
videographics program and to generate a video 
graphics display output; 

a second processor that is operable to perform 
^5 videographics program editing operations and 

to generate an editing related display output; 
and 

superimpose control circuitry for superimpos- 
ing said editing related display output onto said 
50 videographics program display output. 

2. A videographics program editing system according 
to claim 1, further including at least one picture 
processing unit coupled to said first processor and 

55 said second processor for generating a videograph- 
ics display on said display screen. 

3. A videographics program editing system according 
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to claim 1, further including a bus coupled to said 
first processor a memory device coupled to said 
bus for storing information on said bus, said second 
processor being operable to monitor the contents 
of said memory device to determine the appropriate 
time to stop the execution of said videographics pro- 
gram. 

4. A videographics program editing system according 
to claim 1, further including a control register cou- 
pled to said second processor a first memory cou- 
pled to said first processor and a removable car- 
tridge including a second memory coupled, in use, 
to said first processor said first processor being 
operable to initially execute instructions out of said 
first memory and to subsequently execute instruc- 
tions out of said second memory depending upon 
the state of said control register 

5. In an interactive computing system for editing a vid- 
eographics program having a first processor that is 
operable to execute a videographics program and 
to generate a videographics display output signal 
and a second processor that is operable to perform 
videographics editing operations and to generate 
an editing related display output signal superim- 
pose control circuitry comprising: 

an overlay control signal generating circuit for 
receiving at least one overlay control input sig- 
nal for generating an overlay control output sig- 
nal: and 

gating circuitry, coupled to receive said video- 
graphics program display output and said edit- 
ing related display output, and for selectively 
outputting one of said display output signals 
depending on the state of said overlay control 
output signal. 

6. Superimpose control circuitry according to claim 5, 
wherein said overlay control output signal is a trans- 
parency control related signal from at least one of 
said first processor and said second processor 



frames associated with a videograhics program 
using an interactive computing system including a 
display device having a display screen comprising 
the steps of: 

5 

executing a videographics program having a 
sequence of display frames to be modified: 
stopping the sequence of display frames at a 
desired editing point and displaying a frame to 
10 be edited: and 

superimposing an editing window on said dis- 
play frame, whereby a user may select between 
a plurality of editing options. 

15 10. A method of creating according to claim 9, wherein 
said computing system includes at least one input 
device and wherein said step of stopping the 
sequence of display frames includes the step of dis- 
playing a display frame that the user desires to edit 

20 on said display screen and detecting when a user 
generates a predetermined signal using said input 
device. 

11. A method of creating according to claim 9, further 
25 including the step of detecting a user's identification 

of a displayed character to be modified. 

12. A method of creating according to claim 11 , further 
including the step of displaying an editing window 

30 for choosing an editing operation to perform relating 
to the user identified character 

13. A method of editing according to claim 12, further 
including the step of changing the character pattern 

35 of said character 

14. A method of creating according to claim 12, further 
including the step of changing the pattern of move- 
ment associated with the user identified character 



40 



15. A method of creating according to claim 9, further 
including the step of detecting a user's identification 
of the display frame background for modification. 



7. Superimpose control circuitry according to claim 5, 
further including a control register which is loaded 
by said second processor the state of said control 
register determining the overlay control signal gen- 
erating circuit output signal coupled to said gating 
circuitry. 

8. Superimpose control circuitry according to claim 5, 
wherein said overlay control input signal controls 
the priority of transparency between the display out- 
put of said first processor and the display output of 
said second processor 



•^5 16. A method of creating according to claim 1 5, further 
including the step of changing the bakground 
screen displayed at the point the sequence of dis- 
play frames was stopped. 



50 



17. A method of creating according to claim 9, further 
including the step of changing the audio associated 
with said background screen. 
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9. A method of creating a unique sequence of display 
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